Subject: Re: [dtn-interest] Question regarding status...
From: Daniel Ellard <[email-masked]>
To: Sten-Erik Björling <[email-masked]>
Cc: DTN <[email-masked]>
Date: Wed, 27 Jan 2010 10:48:14 -0500
List-Id: Delay Tolerant Networking Interest List <dtn-interest.maillists.intel-research.net>

Sten-Erik Björling wrote:
> Hi all,
> 
> We are now in the process of testing approaches for
> applications utilizing different transmission methods of
> complex data - this data will be packaged in a single
> file containing different sizes of data of different
> types with complete access control and encryption.

I'm not sure I understand the questions, but perhaps my
answers will help anyway--to clarify the questions, if
nothing else.

> I want to know the following:
> 
> - Can the current DTN / DTN2 approaches support
> non-destructive transmission of a complete file from one
> place to another?

DTN is not file-oriented.  It is bundle-oriented.  If you
have an app that puts a file into a bundle and passes it via
DTN to some other app (or apps) elsewhere on the network,
nothing happens to the original file, unless the app does
something destructive to it.  DTN is not destructive.

> - Eventual size limitations?

In theory, there are is no practical limitation on the size
of bundles.  In practice, some implementations start to have
issues with bundles larger than 2GB (or 4GB) because their
implementations take shortcuts.  Nothing that can't be fixed.

> - Does this ability exist in both web, mail and ftp
> implementations of the technology?

DTN is orthogonal to web, mail, or ftp.

You could use DTN to implement an underlay for web, mail, or
ftp.  It's been done.

You could use http, mail, or ftp to implement a convergence
layer for DTN.  Someone has probably done this, just for the
pleasure of it, but it's not the usual way.

You could even do both: use mail as a convergence layer for
a DTN implementation used by an app to move mail around.

> - Any current estimates of secure delivery and
> non-swamping of communication networks by massive
> parallel sending of the materials (have hint-based
> approaches been implemented yet?).

Don't know.

> - Do it exist GUI-less and "clean" java-implementations
> of DTN/DTN2?

GUI-less: that's typically the case.

Pure java: I think I've heard of one, but I don't recall
whether it's pure java.

Java-api: yes, several.

> Is there any research covering the
> interfacing of DTN with grid networks?

I'm not aware of any, but that doesn't mean that the answer
is no.  Usually the GRID folk start with an assumption that
the network is essentially reliable and available
end-to-end.  DTN exists to deal with networks where that
assumption might never be true.  There are grey areas in
between: you might want to construct a grid that can
tolerate some subset of the space of possible disruptions,
and DTN can help with that.

-Dan

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

Date: Wed, 27 Jan 2010 14:52:29 +0000
From: Stephen Farrell <[email-masked]>
To: Andrei Gurtov <[email-masked]>
Cc: DTN <[email-masked]>, Elwyn Davies <[email-masked]>
Subject: Re: [dtn-interest] review of draft-irtf-dtnrg-bundle-security-12 (was Re: [IRSG] DTNRG review assignments)

Hi Andrei,

Thanks for the review, glad you found the document (almost)
ready. We've (actually, Peter) done an update that I think
takes all those into account. [1]

As to your questions about ECC, firstly anyone can define new
ciphersuites for ECC if they're interesting, so it can be
added later. Secondly, we basically picked the most IPR-clean
and widely implemented algorithms for this spec, and ECC is
unfortunately not top of the list in either respect.

And yes, there's an implementation, done by Peter Lovell.

I guess the next step if you're happy with -14 is for you
to mail the irsg list to say that, then Elwyn can update
the ticket and start the irsg poll.

Thanks again,
Stephen.

[1] http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-security

Andrei Gurtov wrote:
> 
> Hi Elwyn,
> 
> I've read the document through several times and I think it's ready to
> publish. The document is very well written and apparently has been
> already reviewed thoroughly by the RG since the text is quite clear and
> generally bug-free. The document structure is intuitive and proposed
> solutions appear very reasonable. Having a generic ASB in other block
> descriptions seems neat (could be called a common header in other
> terminology).
> 
> Some security experts might want to see an attack model to be explicitly
> stated in the beginning of the document. I.e. it's assumed that attacker
> could eavesdrop or modify the messages in transit but not directly
> compromise DTN nodes, etc.
> 
> The presently defined 4 cryptographic suits include traditional RSA and
> SHA algorithms with larger key sizes. However those take plenty of space
>  and processing time and ECC is better almost an order of magnitude both
> in space and processing time. This might be important for resource- and
> bandwidth- restricted environments where DTNs could operate. It would be
> good to see some discussion on this issue, and why not make ECC the
> default suites. There are some IPR issues perhaps, but at least latest
> openssl library includes free open-source ecc code.
> 
> In fig 2 and other similar ones there is no numbering of bits
> traditionally present in RFCs. It would be perhaps a good idea to
> include those, especially since the bit numbering could be from right to
> left in some cases (if I understood correctly from other examples).
> 
> Fig 6 and 7 look exactly the same, are both of them needed?
> 
> Has someone actually implemented this specification? It would be nice to
> have a summary of their experiences/pointers to the code, or is this
> planned for a separate document?
> 
> Some minor nits and typos are also marked on the attached PDF.
> 
> Best regards
> Andrei
> 
> 
> 
> Elwyn Davies wrote:
>> Aaron Falk wrote:
>>> Yes, please!
>>>
>>> I'll send a note to Lachlan.
>>>
>>>   
>> Hi, Andrei.
>> Thanks for agreeing to review this draft.
> 
>> I hope to see your review in the first week of 2010 if that is possible
>> given the holidays.
> 
>> Regards,
>> Elwyn Davies
>> Document Shepherd
> 
> 
>>> --aaron
>>>
>>> On 12/10/09 6:36 AM, Andrei Gurtov wrote:
>>>  
>>>> Hi,
>>>>
>>>> I've agreed earlier to review  the security draft, which I read a couple
>>>> times already. Do you want me still to write the review?
>>>>
>>>> Andrei
>>>>
>>>> Aaron Falk wrote:
>>>>    
>>>>> Hi Folks-
>>>>>       Here are the reviewer assignments for the DTNRG docs listed
>>>>> below.
>>>>>       Andrew, L
>>>>>     [email-masked]    
>>>>> http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-security
>>>>> Arbaugh, W
>>>>>     [email-masked]             
>>>>  http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv
>>>>    
>>>>> Braden, R
>>>>>     [email-masked]             
>>>>  http://tools.ietf.org/html/draft-irtf-dtnrg-cbhe
>>>>    
>>>>> Wroclawski, J
>>>>>     [email-masked]    
>>>>> http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-previous-hop-block
>>>>> Zhang, L
>>>>>     [email-masked]    
>>>>> http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-metadata-block
>>>>>       
>>>>    
>>>>> Please send a confirmation that you will agree to do the reviews.  If
>>>>> you haven't confirmed by Monday, 12/14/09, Elwyn should start chasing
>>>>> after you.  Reviews should be done in 2-3 weeks but given the holiday,
>>>>> you might want to pick a date that is reasonably convenient and confirm
>>>>> for that date.
>>>>>       Remember, the reviews are scoped as follows
>>>>> (http://trac.tools.ietf.org/group/irtf/trac/wiki/IRTF-RFCs#Reviews):
>>>>>           Reviews
>>>>>           The purpose of the IRSG review is to ensure consistent
>>>>> editorial and
>>>>>     technical quality for IRTF publications. IRSG review is not a deep
>>>>>     technical review. (This should take place within the RG.) At least
>>>>>     one IRSG member other than the chair of the RG bringing the work
>>>>>     forth must review the document and the RG's editorial process.
>>>>>           IRSG reviewers should look for clear, cogent, and consistent
>>>>>     writing. An important aspect of the review is to gain a critical
>>>>>     reading from reviewers who are not subject matter experts and, in
>>>>>     the process, assure the document will be accessible to those beyond
>>>>>     the authoring research group. Also, reviewers should assess whether
>>>>>     sufficient editorial and technical review has been conducted and
>>>>> the
>>>>>     requirements of this process document, such as those described in
>>>>>     Group Preparation
>>>>>    
>>>>> <http://trac.tools.ietf.org/group/irtf/trac/wiki/IRTF-RFCs#Research>
>>>>>     have been met. Finally, reviewers should check that appropriate
>>>>>     citations to related research literature have been made.
>>>>>           Reviews should be written to be public. Review comments
>>>>> should be
>>>>>     sent to the IRSG and RG mailing lists and entered into the tracker.
>>>>>     All IRSG review comments must be addressed. However, the RG need
>>>>> not
>>>>>     accept every comment. It is the responsibility of the shepherd to
>>>>>     understand the comments and ensure that the RG considers them
>>>>>     including adequate dialog between the reviewer and the author
>>>>> and/or
>>>>>     RG. Reviews and their resolution should be entered into the tracker
>>>>>     by the document shepherd.
>>>>>       --aaron
>>>>>       On 11/23/09 8:47 AM, Stephen Farrell wrote:
>>>>>      
>>>>>> Hi all,
>>>>>>
>>>>>> DTNRG have finished 5 drafts, with one more hopefully
>>>>>> coming this week. (I'll send a separate note when
>>>>>> that's ready.)
>>>>>>
>>>>>> We're looking for reviewers for these, so if you'd
>>>>>> like to volunteer, please let Elwyn know (he's agreed
>>>>>> to shepherd these for us) and he'll update the
>>>>>> tickets. Otherwise I guess Aaron will allocate people
>>>>>> using his round-robin scheme.
>>>>>>
>>>>>> The drafts are:
>>>>>>
>>>>>> http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-security
>>>>>> http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv
>>>>>> http://tools.ietf.org/html/draft-irtf-dtnrg-cbhe
>>>>>> http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-metadata-block
>>>>>> http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-previous-hop-block
>>>>>>
>>>>>> The first one is by far the longest/most complex (hint, hint:-)
>>>>>>
>>>>>> Thanks,
>>>>>> Stephen.
>>>>>>
>>>>>> _______________________________________________
>>>>>> IRSG mailing list
>>>>>> [email-masked]
>>>>>> http://mailman.isi.edu/mailman/listinfo/irsg
>>>>>>
>>>>>>         
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>       _______________________________________________
>>>>> IRSG mailing list
>>>>> [email-masked]
>>>>> http://mailman.isi.edu/mailman/listinfo/irsg
>>>>>       
>>>>     
>>>   
> 
> 

From: =?iso-8859-1?Q?Sten-Erik_Bj=F6rling?= <[email-masked]>
Date: Wed, 27 Jan 2010 15:00:05 +0100
To: DTN <[email-masked]>
Subject: [dtn-interest] Question regarding status...

Hi all,

We are now in the process of testing approaches for applications utilizing different transmission methods of complex data - this data will be packaged in a single file containing different sizes of data of different types with complete access control and encryption.

I want to know the following:

- Can the current DTN / DTN2 approaches support non-destructive transmission of a complete file from one place to another?

- Eventual size limitations?

- Does this ability exist in both web, mail and ftp implementations of the technology?

- Any current estimates of secure delivery and non-swamping of communication networks by massive parallel sending of the materials (have hint-based approaches been implemented yet?).

- Do it exist GUI-less and "clean" java-implementations of DTN/DTN2? Is there any research covering the interfacing of DTN with grid networks?

We will not start to look into this in a more detailed fashion until summer but some info already today would be nice.

Take care all,

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

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

Date: Mon, 25 Jan 2010 22:59:10 +0100
From: Aline Carneiro Viana <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CFP: IEEE MASS 2010

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

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

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

                November 2010 - San Francisco, CA, USA
==========================================================================

IMPORTANT DATES:

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

SCOPE:

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

TOPICS OF INTEREST:

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

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

WORKSHOPS:

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

=================================================================================
GENERAL CO-CHAIRS

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

PROGRAM CO-CHAIRS

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

TPC SUB-AREA CHAIRS

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

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

- Algorithms and theory
Dong Xuan, Ohio State University

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

WORKSHOP CO-CHAIRS

Cedric Westphal, DoCoMo Labs
Christine Pepin, DoCoMo Labs

DEMO CHAIR

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

WEB CHAIR

Venkatesh Rajendran, Wionics

FINANCE AND REGISTRATION CHAIR

Zhen Jiang, West Chester University

PUBLICATION CHAIR

Dajin Wang, Montclair State University

PUBLICITY CHAIR

Aline Carneiro Viana, INRIA

LOCAL ARRANGEMENTS CO-CHAIRS

Kumar Viswanath, NTT Labs
Ignacio Solis, PARC

STEERING COMMITTEE CHAIR

Dharma P. Agrawal, University of Cincinnati

CHAIR OF IEEE TC ON DISTRIBUTED PROCESSING

Jie Wu, US National Science Foundation

CHAIR OF IEEE TC ON SIMULATION

Dave Cavalcanti, Phillips Research

Date: Mon, 18 Jan 2010 11:27:11 +0000
From: Fehmi Ben Abdesslem <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] ACM HotPlanet 2010 workshop (co-located with ACM MobiSys) - Call For Papers

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

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

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

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

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

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

SUBMISSION GUIDELINES

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

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

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

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

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

-- 
Fehmi Ben Abdesslem
Postdoctoral Researcher
Networked and Distributed Systems

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

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

The University of St Andrews is a charity registered in Scotland: No 
SC013532

Date: Fri, 15 Jan 2010 17:27:32 -0200
From: "Antonio Alfredo F. Loureiro" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Elsevier's Information Fusion Journal, Special Issue on Localized Algorithms for Information Fusion in Resource-Constrained Networks

[Apologies for cross-postings. Please send it to interested
colleagues and students. Thanks!]

Elsevier's Information Fusion Journal, Special Issue on "Localized
Algorithms for Information Fusion in Resource-Constrained Networks"
http://www.elsevierscitech.com/lmfile/otherformat/IFJ-CFP-RCN-Final.pdf

Submission Deadline: February 28, 2010

The Information Fusion Journal (IFJ), an Elsevier publication (JCR 2008: 
2.057), is planning a special issue devoted to Localized Algorithms for 
Information Fusion in Resource-Constrained Networks.
Resource-Constrained Networks (RCNs) include a wide variety of networks
in which resources - such as processing, communication, and energy - are 
limited. Examples of RCNs include ad hoc networks, sensor networks,
mobile networks, and pervasive systems. In RCNs, the tradeoff between
data quality and resource usage (especially energy) is a major concern.
In this case, Localized Algorithms and Information Fusion are
particularly interesting for RCNs, since the development of efficient
practical solutions and algorithms is possibly the most challenging task 
for such networks. On one hand, Localized Algorithms are special
distributed algorithms in which only a subset of nodes partakes in the
network tasks, such as data acquisition, processing, and communication.
On the other hand, Information Fusion is often used for improving the
quality of data being transmitted in these networks. Thus, Localized
Algorithms for Information Fusion must deal with the challenge of
working with partial views, or incomplete data, to provide accurate
results at reduced cost.

This special issue will cover a broad range of aspects of Localized
Algorithms for Information Fusion in RCNs, including ad hoc and mobile
networks, wireless sensor networks, networked pervasive systems. We seek 
technical papers describing original (previously unpublished in any form 
or forum) ideas, groundbreaking results, and quantified system
experiences. We especially encourage submissions that highlight
practical deployments of RCNs, new application domains, and critical
surveys of the state-of-the-art. Topics of interest for this special
issue include, but are not limited to:

- In-network query processing and data storage;
- Localized signal processing;
- Localized estimation, reasoning, and inference;
- Localized information fusion for time synchronization;
- Localized information fusion for location discovery and location-based 
services;
- Localized information fusion for reliability and fault tolerance;
- Localized information fusion for communication protocols at all layers 
(MAC, scheduling, routing, transport, and application);
- Quality-aware resource management using localized information fusion;
- Mobility control and coordination;
- Optimization techniques for localized information fusion in
homogeneous and heterogeneous RCNs;
- Localized information fusion for data compression and distributed
source coding.

Manuscripts must describe original, completed, and unpublished work not
currently under review by any other journal, magazine, or conference.

Submission Instructions

Prospective authors should follow the Information Fusion (Elsevier)
journal manuscript format described at
http://www.elsevier.com/locate/inffus. Manuscripts should be submitted
electronically online at http://ees.elsevier.com/inffus. In the
submission process, the authors should clearly indicate that the
submission is to be considered for this special issue. Manuscripts must
be in single-column format, doublespaced, at least 11 pt fonts, and
should not exceed 25 pages including figures, tables, algorithms, and
references. Simultaneously, please also send without fail an electronic
copy (PDF only), to  the Guest Editor(s) listed below.

Submission Deadline: February 28, 2010

Guest Editors:

Dr. Eduardo F. Nakamura
Center of Analysis, Research, and Technological
Innovation, FUCAPI, Brazil
E-mail: [email-masked]
URL: http://www.nakamura.eti.br/eduardo

Dr. Antonio A. F. Loureiro
Federal University of Minas Gerais, Brazil
E-mail: [email-masked]
URL: http://www.dcc.ufmg.br/~loureiro

Dr. Azzedine Boukerche
University of Ottawa, Canada
E-mail: [email-masked]
URL: http://www.site.uottawa.ca/~boukerch/

Dr. Albert Y. Zomaya
University of Sydney, Australia
E-Mail: [email-masked]
URL: http://www.cs.usyd.edu.au/~zomaya

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 15 Jan 2010 07:09:51 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] DTN Tic-Tac-Toe Application using SimpleBP API

Many thanks to Greg Campbell of Ohio University.   Greg placed a link to the DTN Tic Tac Toe application on the DTNRG wiki.  This application demonstrates the use of the Simple Bundle Protocol API. There's a tarball which contains the source, a makefile, & some instructions.

The link is available in two locations (I duplicated the link under DtnBone/DtnApps as in the future I expect it would be easier to find there.

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

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

--Will

Content-Class: urn:content-classes:message
Date: Wed, 13 Jan 2010 14:25:05 -0700
From: "Moore, Brad" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] [SPAM] - Re: QoS in DTN - Email found in subject

Thanks Ioannis, a very interesting paper. In my mind this points out a
potential area of improvement for the Bundle Protocol. How can an
application mark a bundle so that bundle agents can make more
intelligent
routing decisions?

Within the constraints of the current definition of the Bundle Protocol,
I suppose one could achieve this by defining special EID schemes.
For example, I envision a simple scheme where delivery hints can be
optionally
specified in order of importance like;

"dtn(CS):\\"

Where

S could represent maximizing Successful Delivery 
D could represent minimizing Delay time
P could represent minimizing power consumption
etc

So for example, if an application wished to send an email bundle to
nodeA, 
It might specify a destination EID of "dtn(S)://nodeA/email" to indicate
that delivery success
is of high importance. An intermediate hop configured to minimize power
consumption
might be configured to only forward bundles if it has a known route to
the destination. Such a node
normally might not use probabilistic strategy, or a flooding strategy,
and hold onto bundles until
a known path is determined (such as through a DTLSR like strategy).
However, when receiving a bundle
flagged with a Delivery Success importance hint, the intermediate node
might decide to take a best effort 
approach, and select a routing strategy such as ProPhet or Epidemic
Flooding to increase the probability
of delivery.

The absence of delivery hints on the EID would mean that the Bundle
Agent on the intermediate node would
Default to its normal routing strategy.

Another way to provide these inputs would be to provide some sort of
field in the bundle header, but
I presume that would mean the Bundle Protocol would need modification,
which I presume is to be avoided.

Are there any other suggestions?

Regards,

Brad Moore

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, January 12, 2010 2:40 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [SPAM] - Re: [dtn-interest] QoS in DTN - Email found in
> subject
> 
> Hi all,
> 
> in a recent position paper, [1], we've discussed/proposed service
> differentiation techniques for DTNs. We've concluded that the service
a
> user receives depends on the application running on top, since the
> application's "satisfaction" is what really matters and applications'
> requirements differ massively. We used Delivery Delay and Delivery
> Reliability as the ultimate service metrics. As Elwyn pointed, there's
> no way an end-user can define/specify delay-thresholds, or at least
> this would probably not scale. At the same time, however, a more
> globally defined system of rules, where bundle expirations and
> forwarding decisions are made based on the applications has better
> potential of achieving good performance in opportunistic connectivity
> nets.
> 
> Cheers,
> Ioannis.
> 
> [1] http://personal.ee.surrey.ac.uk/Personal/I.Psaras/extremecom09-
> ipsaras.pdf
> 
> ________________________________________
> From: [email-masked] [dtn-interest-
> [email-masked]] On Behalf Of Elwyn Davies
> [[email-masked]]
> Sent: 05 January 2010 07:51
> To: Ma Xuebin
> Cc: dtn-interest
> Subject: Re: [dtn-interest] QoS in DTN
> 
> Hi.
> 
> Measuring the delivery effectiveness of a DTN network is much
discussed
> in the literature on routing in opportunistic networks.  This paper
> http://www.cs.umass.edu/~arun/papers/RAPID.pdf on the RAPID routing
> protocol is a good start.  Delivery effectiveness is probably the best
> measure of the 'QoS' of a DTN, but what exactly this means is a matter
> of ongoing discussion.
> 
> As with conventional IP networks, there is no way that the end user
can
> seriously hope to specify the delay to be tolerated and have this
> honored by the network.  The best that can be done is for the end
> user/application to determine a time when the contents of a given
> message is no longer useful and set this as the expiry time of the
> bundle containing the data.  Actually DTN is more helpful in this than
> conventional IP networks because ther is no way to control this expiry
> time in IP (we try very hard to ignore time in IP networks!)
> 
> RFC 5050 in principle offers a small set of priorities that can be
> applied to bundles.  As with IP, trying to apply these to user bundles
> is probably impractical for many of the same reasons that are
discussed
> in the IP literature (authorization, priority escalation, DoS, etc.)
> 
> As you may gather, I am what might be described as a 'QoS Sceptic'.
> Trying to persuade an end user that s/he has any sort of control over
> the delivery of an individual packet/bundle is at best a fantasy and
at
> worst a cruel con trick.  This is primarily because in general the
> network does not have much/any control knobs that can be adjusted to
> affect this delivery. OTOH post-facto measurement of what happened and
> doing statistical analysis is clearly possible and desirable.
> 
> Regards,
> Elwyn Davies
> 
> Ma Xuebin wrote:
> > Hi all,
> >
> > How to understand the QoS in DTN? We know the delay is an important
> > factor to be considered in QoS , but which is tolerated in DTN. Does
> > this mean that delay is not need considered in QoS of DTN? If so,
> then
> > we focus on what kind of factors?
> >
> > 2010-01-05
> >
---------------------------------------------------------------------
> ---
> > Ma Xuebin
> >
---------------------------------------------------------------------
> ---
> >
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> >
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. 
Thank you. 

Sender: [email-masked]
From: Pablo Serrano <[email-masked]>
Date: Wed, 13 Jan 2010 19:41:35 +0100
To: [email-masked]
Subject: [dtn-interest] [Reminder] 2nd IEEE WoWMoM Workshop on Hot Topics in Mesh Networking

The Second IEEE WoWMoM Workshop on Hot Topics in Mesh Networking (HotMESH 2010)

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

Montreal, Canada June 14, 2010

In conjunction with the 11th IEEE International Symposium on a "World
of Wireless, Mobile and Multimedia Networks" (WoWMoM’10)

http://wowmom2010.netgroup.uniroma2.it/
----------------------------------------------------------------------

THEME AND SCOPE
The huge advances of wireless broadband technologies lay the
foundation of a future where ubiquitous wireless network access will
be anywhere at anytime. Wireless mesh networks are expected to be a
key element of this future by providing a highly scalable, reliable
and cost-effective wireless backbone to mobile devices a multi-hop
wireless communication system. However, there are still a lot of
technical challenges that need to be solved in order to reach the full
potentialities of this innovative technology.

This workshop aims to bring together the technologist and researchers
who share interest in the area of wireless mesh networks. The main
purpose is to promote discussions on recent advances in the analysis
design and implementation of systems, protocols and services for next
generation mobile mesh networks. It also aims at increasing the
synergy between academic and industry professionals working in this
area. We plan to seek papers that address theoretical, experimental,
and work in-progress at all layers of mesh networks, from application
to physical layer.

Topics of interest include, but are not limited to:

   Cross layer design and optimizations
   Capacity analysis
   Greening the Internet
   Multi-radio and multi-channel wireless mesh networking
   Medium access control protocols
   Self-configuration and self-management procedures
   Routing, scheduling, and channel assignment protocols
   Mesh networks measurement
   QoS provisioning
   Mobility management
   Topology construction and maintenance
   Security architectures, functions and protocols
   Privacy enhancing technologies for mesh networks
   Testbed, prototype, and practical systems

PAPER SUBMISSIONS
Authors should prepare a PDF file following the IEEE 8.5x11 conference
format in accordance with the IEEE Computer Society author guidelines
(http://www.computer.org/portal/web/cscps/formatting). Manuscripts
should not exceed six (6) pages in size including all text, figures,
tables, and references. Papers significantly exceeding this limit will
be automatically rejected. Attendance to the workshop will require a
Full Registration to the main conference. Accepted papers will be
published by the IEEE Computer Society Press in the combined WoWMoM
2010 workshop proceedings. Accepted papers not presented at the
workshop will not be included in the IEEE Digital Library.

IMPORTANT DATES
Submission due:          February 5, 2010
Acceptance notification:        March 25, 2010
Final manuscript due:            April 10, 2010
Workshop:                 June 14, 2010

WORKSHOP CO-CHAIRS
Albert Banchs, Univ. Carlos III de Madrid, Spain
Raffaele Bruno, IIT-CNR, Italy

PUBLICITY CHAIR
Pablo Serrano, Univ. Carlos III de Madrid, Spain

PROGRAM COMMITTEE
Kevin C. Almeroth, University of California Santa Barbara, USA
Emilio Ancilotti, IIT-CNR, Italy
Vangelis Angelakis, University of Linköping, Sweden
Michael Bahr, Siemens AG, Germany
Boldizsar Bencsath, Budapest University of Tech. and Economics, Hungary
Vartika Bhandari, University of Illinois at Urbana-Champaign, USA
Matteo Cesana, Politecnico di Milano, Italy
Vania Conan, Thales, France
Marc Emmelmann, Technical University of Berlin, Germany
Rosario Garroppo, University of Pisa, Italy
Mario Gerla, University of California Los Angeles, USA
Bernd Gloss, Bell Labs, Alcatel Lucent, Germany
Isabelle Guerin-Lassous, ENS Lyon, France
Andreas Kassler, Karlstad University, Sweden
Enzo Mingozzi, University of Pisa, Italy
Antonio Pinizzotto, IIT-CNR, Italy
George C. Polyzos, Athens University of Economics and Business, Greece
Marius Portmann, University of Queensland, Australia
Salvatore Vanini, SUPSI, Switzerland
Frank Zdarsky, NEC Europe Ltd, Germany

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 12 Jan 2010 14:29:23 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] UPDATE:  Meeting Notes  for January 8, 2010 DTN Network Management

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

Most of the material has been posted.  I need the CCSDS Green Book outline =
from Ed Birrane (APL) and I asked Gilbert Clark (Ohio University) if he wou=
ld post the tic-tac-toe game that was written using the SimpleBP API.

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

-- Will

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

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family: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:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","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.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
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:12.0pt;
	font-family:"Times New Roman","serif";}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
span.EmailStyle20
	{mso-style-type:personal-compose;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:568879113;
	mso-list-template-ids:-139017960;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l1
	{mso-list-id:986937692;
	mso-list-type:hybrid;
	mso-list-template-ids:685176912 67698689 67698691 67698693 67698689 676986=
91 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l1:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l1:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l1:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2
	{mso-list-id:1363214762;
	mso-list-type:hybrid;
	mso-list-template-ids:-1607709538 67698689 67698691 67698693 67698689 6769=
8691 67698693 67698689 67698691 67698693;}
@list l2:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l2:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l2:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l3
	{mso-list-id:1473672209;
	mso-list-type:hybrid;
	mso-list-template-ids:1482296460 67698689 67698691 67698693 67698689 67698=
691 67698693 67698689 67698691 67698693;}
@list l3:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:42.0pt;
	text-indent:-.25in;
	font-family:Symbol;}
@list l3:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l3:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l3:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l3:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l3:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l3:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l3:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l3:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l4
	{mso-list-id:1996833863;
	mso-list-template-ids:1316779008;}
@list l4:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l4:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l4:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l4:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l4:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l4:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l4:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l4:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l4:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
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=3DMsoPlainText>Most of the material has been posted.&nbsp; I need =
the
CCSDS Green Book outline from Ed Birrane (APL) and I asked Gilbert Clark (O=
hio
University) if he would post the tic-tac-toe game that was written using th=
e
SimpleBP API.<o:p></o:p></p>

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

<p class=3DMsoPlainText><a
href=3D"http://www.dtnrg.org/wiki/DtnBone/JanNetManMeeting">http://www.dtnr=
g.org/wiki/DtnBone/JanNetManMeeting</a><o:p></o:p></p>

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

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

<p class=3DMsoPlainText>-- Will<o:p></o:p></p>

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

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

</div>

</body>

</html>

--_000_3A5AA67A8B120B48825BFFCF544385619480BD778CNDJSSCC03ndcn_--

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 12 Jan 2010 11:17:03 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Meeting Notes  for January 8, 2010 DTN Network Management

--_000_3A5AA67A8B120B48825BFFCF544385619480BD75F0NDJSSCC03ndcn_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

(Note, I hope to have most of the items below on the dtnrg wiki by COB toda=
y.)

-- Will

DTN Network Management - Collaborators
Meeting Notes for Technical Exchange Meeting
Friday, January 8, 2010
8:30 - 14:30 EST (13:30 - 19:30 UTC)

A Technical Exchange Meeting was held on Friday, January 8, 2010 at Ohio Un=
iversity in Athens, Ohio.  Remote attendance was available via teleconferen=
ce and WebEx.

These notes are to document that meeting and have been generated by Will Iv=
ancic.
See DTNRG wiki for additional information and slides.
http://www.dtnrg.org/wiki/DtnBone/JanNetManMeeting

Participants (I may have missed some or included some that really were not =
on)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 *   BBN - Cambridge (Josh Bers, John Zinky)
 *   Ohio University (Hans Kruse, Shawn Ostermann, Gregg Campbell, Clark Gi=
lbert, David Young)
 *   NASA Glenn (Will Ivancic, Alan Hylton, Jim McKim, Denis Iannicca, Jose=
ph Ishac)
 *   N4C (Elwyn Davies, Avri Dori)
 *   Viagenie (?)
 *   Applied Physics Lab (Ed Birrane)

Agenda: Start Time is 8:30 EST (13:30 UTC)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
1) N4C-lessons learned from field trials and desired network management fea=
tures/capabilities
2) Monitoring
   2a) DTN-2
       2a1) Local Management in DTN2 (discussion and demonstration)- McKim
       2a2) Extending DTN2 local management to Remote Management - McKim
   2b) ION Network Management
       2b1) Local Management in ION - Ohio University
       2b2) Remote Management in ION - Ohio University
3) Configuration Management - APL
   (ION "load and go", others ...)
   -- Automated Fault Detection (APL)
4) CCSDS Green Book on Network Management for Space-based systems
    -- (For non-CCSDS people, a Green Book is equivalent to an Informationa=
l RFC)
5) DTNbone Discussions
   -- DTN disconnection topology
   -- Dynamic routing
   -- Security Test Keys???
   -- Test and debug tools (e.g. Wireshark and others)
6) Common API
   -- Network Performance and Troubleshooting Utilities
      (DTNtraceroute, DTNperf, heartbeat, etc...)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
1) N4C-Avri Dori and Elwyn Davis provided some lessons learned from field t=
rials and desired network management features/capabilities.  N4C is very in=
terested in getting some of the Code NASA and Ohio University (OU) are work=
ing and begin playing with this.

2) Monitoring and Configuration

Ohio University (OU) and NASA Glenn Research Center (GRC)have strategically=
 decided to split Network Management implementations such that OU works on =
ION while GRC works DTN2

Jim McKim present current state of Network Management for DTN2 (Slides on l=
ine)

=B7         Local management is via SNMP agent.

=B7         BBN MIP document used as starting point.  Jim fixed and added i=
tems to MIB.

=B7         A new command was added to the User Interface to enable "get" c=
ommands.

=B7         To generate DTN bundles, the JavaScript Object Notation (JSON) =
is used.  JSON is a lightweight data-interchange format. It is easy for hum=
ans to read and write. It is easy for machines to parse and generate and it=
 is readily available.

o    Bundles can be a bit large, but we can adopt OU "schema" concepts late=
r that basically are pre-configured compression as JSON bundles allow early=
 flexibility.

(Side Note: Meeting discussion resulted in the notion that it is better ear=
ly on to be less concerned about bandwidth utilization and more concerned a=
bout getting tools out to enable the community to begin figuring out how to=
 do DTN Network Management.)

=B7         Need to figure out the best way to distribute the code.

Greg Campbell and Gilbert Clark presented OU's approach to network manageme=
nt - slides on line.  The basic idea is to have a SNMP gateway.  SNMP is ex=
changed between the management system and the gateway.  The gateway respond=
s in real time to the SNMP with cached data and obtains the data via bundli=
ng.  Ohio University personnel are developing a network management protocol=
 call DING.  An Internet Draft should be out in the next few months.  Detai=
l are in the online slides.

3) Configuration Management - APL
Ed Birrane briefly discussed APL's approach to network management base on D=
r. Robert Coles work with MANETs and netconf.

4) CCSDS Green Book on Network Management for Space-based systems

=B7         (For non-CCSDS people, a Green Book is equivalent to an Informa=
tional RFC)

=B7         Ed Birrane went over the outline and some detail of what he wou=
ld like in a CCSDS Green Book.  Idea is to Network Management is rather and=
 requires its own document

=B7         The outline will be made available and put online on the wiki

5) Common API

Gilbert Clark provided a short presentation on the SimpleBP (SBP) API is de=
signed to provide a simple way to code applications which use DTN. In addit=
ion, a tic-tac-toe game was demonstrated that was written using the SBP.  T=
he SBP code is available here:

https://ion.ocp.ohiou.edu/content/sbpapi-065-alpha-1

https://ion.ocp.ohiou.edu/content/sbp-api-documentation

I will see if the tic-tac-toe game could be released as well.

6) DTNbone Discussions

=B7         Ohio University utilized work started by others (BBN?) and comp=
leted bundling extensions for wireshark and was able to get the implementat=
ion into the latest release.  Thus, if you download the latest release of w=
ireshark, you will be able to use this to debug bundles.

=B7         DTN disconnection topology

o    Both OU and GRC agreed that we need some permanently always accessible=
 Disconnected Networks for network management.  It was decided that GRC and=
 OU would put nearly identical network together, on running DTN2 and the ot=
her ION.

o    Three base network types where identified

=A7  One with the first bundle agent reachable in the order of minutes and =
the bundle agent behind the first reachable on the order of tens of minutes=
.

=A7  A second with the first bundle agent reachable in the order of tens of=
 minutes and the bundle agent behind the first reachable on the order of mi=
nutes.

=A7  A third reachable by multiple paths thereby testing dynamic routing.

o    The conceptual network layout is posted on the DTNRG wiki

o    OU and GRC will implement these in virtual machines with the gateway p=
ortions and the network management portions reachable via the Open Internet=
.

Submitted by Will Ivancic 01/12/2010

--_000_3A5AA67A8B120B48825BFFCF544385619480BD75F0NDJSSCC03ndcn_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"=
>
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","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.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
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:12.0pt;
	font-family:"Times New Roman","serif";}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParag=
raphCxSpFirst
	{mso-style-priority:34;
	mso-style-type:export-only;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListPar=
agraphCxSpMiddle
	{mso-style-priority:34;
	mso-style-type:export-only;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagra=
phCxSpLast
	{mso-style-priority:34;
	mso-style-type:export-only;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:986937692;
	mso-list-type:hybrid;
	mso-list-template-ids:685176912 67698689 67698691 67698693 67698689 676986=
91 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l0:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1
	{mso-list-id:1363214762;
	mso-list-type:hybrid;
	mso-list-template-ids:-1607709538 67698689 67698691 67698693 67698689 6769=
8691 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l1:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l1:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2
	{mso-list-id:1473672209;
	mso-list-type:hybrid;
	mso-list-template-ids:1482296460 67698689 67698691 67698693 67698689 67698=
691 67698693 67698689 67698691 67698693;}
@list l2:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:42.0pt;
	text-indent:-.25in;
	font-family:Symbol;}
@list l2:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l3
	{mso-list-id:1996833863;
	mso-list-template-ids:1316779008;}
@list l3:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:10.0pt;
	font-family:Symbol;}
@list l3:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l3:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l3:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l3:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l3:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l3:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l3:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l3:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
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=3DMsoPlainText>(Note, I hope to have most of the items below on th=
e
dtnrg wiki by COB today.)<o:p></o:p></p>

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

<p class=3DMsoPlainText>-- Will<o:p></o:p></p>

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

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

<p class=3DMsoNormal style=3D'text-autospace:none'><a name=3D"OLE_LINK3"></=
a><a
name=3D"OLE_LINK4"></a><a name=3D"OLE_LINK9"></a><a name=3D"OLE_LINK10"><sp=
an
style=3D'font-size:10.0pt;font-family:"Courier New"'>DTN Network Management=
 -
Collaborators<o:p></o:p></span></a></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size=
:10.0pt;
font-family:"Courier New"'>Meeting Notes for Technical Exchange Meeting<o:p=
></o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><a name=3D"OLE_LINK5"></=
a><a
name=3D"OLE_LINK6"><span style=3D'font-size:10.0pt;font-family:"Courier New=
"'>Friday,
January 8, 2010<o:p></o:p></span></a></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size=
:10.0pt;
font-family:"Courier New"'>8:30 &#8211; 14:30 EST (13:30 - 19:30 UTC)<o:p><=
/o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size=
:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size=
:10.0pt;
font-family:"Courier New"'>A Technical Exchange Meeting was held on Friday,
January 8, 2010 at Ohio University in Athens, Ohio.=A0 Remote attendance wa=
s
available via teleconference and WebEx.<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size=
:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size=
:10.0pt;
font-family:"Courier New"'>These notes are to document that meeting and hav=
e
been generated by Will Ivancic.<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size=
:10.0pt;
font-family:"Courier New"'>See DTNRG wiki for additional information and
slides.<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><a
href=3D"http://www.dtnrg.org/wiki/DtnBone/JanNetManMeeting"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>http://www.dtnrg.org/w=
iki/DtnBone/JanNetManMeeting</span></a><span
style=3D'font-size:10.0pt;font-family:"Courier New"'><o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size=
:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size=
:12.0pt;
font-family:"Times New Roman","serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size=
:10.0pt;
font-family:"Courier New"'>Participants (I may have missed some or included
some that really were not on)<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size=
:10.0pt;
font-family:"Courier New"'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:=
p></span></p>

<ul type=3Ddisc>
 <li class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;
     mso-list:l3 level1 lfo1'>BBN &#8211; Cambridge (Josh Bers, John Zinky)=
<span
     style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p>=
</o:p></span></li>
 <li class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;
     mso-list:l3 level1 lfo1'>Ohio University (Hans Kruse, Shawn Ostermann,
     Gregg Campbell, Clark Gilbert, David Young)<o:p></o:p></li>
 <li class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;
     mso-list:l3 level1 lfo1'>NASA Glenn (Will Ivancic, Alan Hylton, Jim Mc=
Kim,
     Denis Iannicca, Joseph Ishac)<o:p></o:p></li>
 <li class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;
     mso-list:l3 level1 lfo1'>N4C (Elwyn Davies, Avri Dori)<o:p></o:p></li>
 <li class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;
     mso-list:l3 level1 lfo1'>Viagenie (?)<o:p></o:p></li>
 <li class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;
     mso-list:l3 level1 lfo1'>Applied Physics Lab (Ed Birrane)<o:p></o:p></=
li>
</ul>

<p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size=
:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
Agenda:
Start Time is 8:30 EST (13:30 UTC)</span><span style=3D'font-size:10.5pt;
font-family:Consolas'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
1)
N4C-lessons learned from field trials and desired network management
features/capabilities<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
2)
Monitoring<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
&nbsp;&nbsp;
2a) DTN-2<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2a1) Local Management in DTN2 (discussion and demonstration)- McKim<o:p></o=
:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2a2) Extending DTN2 local management to Remote Management - McKim<o:p></o:p=
></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
&nbsp;&nbsp;
2b) ION Network Management<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2b1) Local Management in ION - Ohio University<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2b2) Remote Management in ION - Ohio University<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
3)
Configuration Management - APL<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
&nbsp;&nbsp;
(ION &quot;load and go&quot;, others ...)<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
&nbsp;&nbsp;
-- Automated Fault Detection (APL)<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
4) CCSDS
Green Book on Network Management for Space-based systems<o:p></o:p></span><=
/p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
&nbsp;&nbsp;&nbsp;
-- (For non-CCSDS people, a Green Book is equivalent to an Informational RF=
C)<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
5)
DTNbone Discussions<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
&nbsp;&nbsp;
-- DTN disconnection topology<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
&nbsp;&nbsp;
-- Dynamic routing<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
&nbsp;&nbsp;
-- Security Test Keys???<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
&nbsp;&nbsp;
-- Test and debug tools (e.g. Wireshark and others)<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
6)
Common API<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
&nbsp;&nbsp;
-- Network Performance and Troubleshooting Utilities<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(DTNtraceroute, DTNperf, heartbeat, etc...)<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
&nbsp;<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size=
:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size=
:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size=
:10.0pt;
font-family:"Courier New"'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
1)
N4C-Avri Dori and Elwyn Davis provided some lessons learned from field tria=
ls
and desired network management features/capabilities.=A0 N4C is very intere=
sted
in getting some of the Code NASA and Ohio University (OU) are working and b=
egin
playing with this.</span><span style=3D'font-size:10.5pt;font-family:Consol=
as'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Times New=
 Roman","serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
2)
Monitoring and Configuration<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
<o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
Ohio
University (OU) and NASA Glenn Research Center (GRC)have strategically deci=
ded
to split Network Management implementations such that OU works on ION while=
 GRC
works DTN2<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
<o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
Jim
McKim present current state of Network Management for DTN2 (Slides on line)=
<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
<o:p>&nbsp;</o:p></span></p>

<p class=3DMsoListParagraphCxSpFirst style=3D'text-indent:-.25in;mso-list:l=
1 level1 lfo2'><![if !supportLists]><span
style=3D'font-size:10.5pt;font-family:Symbol'><span style=3D'mso-list:Ignor=
e'>=B7<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D'font-size:10.5pt;font-family:=
Consolas'>Local
management is via SNMP agent.=A0 <o:p></o:p></span></p>

<p class=3DMsoListParagraphCxSpMiddle style=3D'text-indent:-.25in;mso-list:=
l1 level1 lfo2'><![if !supportLists]><span
style=3D'font-size:10.5pt;font-family:Symbol'><span style=3D'mso-list:Ignor=
e'>=B7<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D'font-size:10.5pt;font-family:=
Consolas'>BBN
MIP document used as starting point.=A0 Jim fixed and added items to MIB.<o=
:p></o:p></span></p>

<p class=3DMsoListParagraphCxSpMiddle style=3D'text-indent:-.25in;mso-list:=
l1 level1 lfo2'><![if !supportLists]><span
style=3D'font-size:10.5pt;font-family:Symbol'><span style=3D'mso-list:Ignor=
e'>=B7<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D'font-size:10.5pt;font-family:=
Consolas'>A
new command was added to the User Interface to enable &#8220;get&#8221;
commands.<o:p></o:p></span></p>

<p class=3DMsoListParagraphCxSpMiddle style=3D'text-indent:-.25in;mso-list:=
l1 level1 lfo2'><![if !supportLists]><span
style=3D'font-size:10.5pt;font-family:Symbol'><span style=3D'mso-list:Ignor=
e'>=B7<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D'font-size:10.5pt;font-family:=
Consolas'>To
generate DTN bundles, the JavaScript Object Notation (JSON) is used.=A0 JSO=
N is a
lightweight data-interchange format. It is easy for humans to read and writ=
e.
It is easy for machines to parse and generate and it is readily available.<=
o:p></o:p></span></p>

<p class=3DMsoListParagraphCxSpMiddle style=3D'margin-left:1.0in;text-inden=
t:-.25in;
mso-list:l1 level2 lfo2'><![if !supportLists]><span style=3D'font-size:10.5=
pt;
font-family:"Courier New"'><span style=3D'mso-list:Ignore'>o<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; </span></span></s=
pan><![endif]><span
style=3D'font-size:10.5pt;font-family:Consolas'>Bundles can be a bit large,=
 but
we can adopt OU &#8220;schema&#8221; concepts later that basically are pre-=
configured
compression as JSON bundles allow early flexibility.<o:p></o:p></span></p>

<p class=3DMsoListParagraphCxSpLast style=3D'margin-left:1.0in'><span
style=3D'font-size:10.5pt;font-family:Consolas'>=A0<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
(Side
Note: Meeting discussion resulted in the notion that it is better early on =
to
be less concerned about bandwidth utilization and more concerned about gett=
ing
tools out to enable the community to begin figuring out how to do DTN Netwo=
rk
Management.)<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
<o:p>&nbsp;</o:p></span></p>

<p class=3DMsoListParagraphCxSpFirst style=3D'text-indent:-.25in;mso-list:l=
1 level1 lfo2'><![if !supportLists]><span
style=3D'font-size:10.5pt;font-family:Symbol'><span style=3D'mso-list:Ignor=
e'>=B7<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D'font-size:10.5pt;font-family:=
Consolas'>Need
to figure out the best way to distribute the code.<o:p></o:p></span></p>

<p class=3DMsoListParagraphCxSpLast style=3D'margin-left:1.0in'><span
style=3D'font-size:10.5pt;font-family:Consolas'><o:p>&nbsp;</o:p></span></p=
>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
Greg
Campbell and Gilbert Clark presented OU&#8217;s approach to network managem=
ent
&#8211; slides on line.=A0 The basic idea is to have a SNMP gateway.=A0 SNM=
P is
exchanged between the management system and the gateway.=A0 The gateway res=
ponds
in real time to the SNMP with cached data and obtains the data via bundling=
.=A0
Ohio University personnel are developing a network management protocol call
DING.=A0 An Internet Draft should be out in the next few months.=A0 Detail =
are in
the online slides.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
<o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
3)
Configuration Management - APL<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
Ed
Birrane briefly discussed APL&#8217;s approach to network management base o=
n
Dr. Robert Coles work with MANETs and netconf. <o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
=A0<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
4) CCSDS
Green Book on Network Management for Space-based systems<o:p></o:p></span><=
/p>

<p class=3DMsoListParagraphCxSpFirst style=3D'margin-left:42.0pt;text-inden=
t:-.25in;
mso-list:l2 level1 lfo3'><![if !supportLists]><span style=3D'font-size:10.5=
pt;
font-family:Symbol'><span style=3D'mso-list:Ignore'>=B7<span style=3D'font:=
7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D'font-size:10.5pt;font-family:=
Consolas'>(For
non-CCSDS people, a Green Book is equivalent to an Informational RFC)<o:p><=
/o:p></span></p>

<p class=3DMsoListParagraphCxSpMiddle style=3D'margin-left:42.0pt;text-inde=
nt:-.25in;
mso-list:l2 level1 lfo3'><![if !supportLists]><span style=3D'font-size:10.5=
pt;
font-family:Symbol'><span style=3D'mso-list:Ignore'>=B7<span style=3D'font:=
7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D'font-size:10.5pt;font-family:=
Consolas'>Ed
Birrane went over the outline and some detail of what he would like in a CC=
SDS
Green Book.=A0 Idea is to Network Management is rather and requires its own
document<o:p></o:p></span></p>

<p class=3DMsoListParagraphCxSpMiddle style=3D'margin-left:42.0pt;text-inde=
nt:-.25in;
mso-list:l2 level1 lfo3'><![if !supportLists]><span style=3D'font-size:10.5=
pt;
font-family:Symbol'><span style=3D'mso-list:Ignore'>=B7<span style=3D'font:=
7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D'font-size:10.5pt;font-family:=
Consolas'>The
outline will be made available and put online on the wiki<o:p></o:p></span>=
</p>

<p class=3DMsoListParagraphCxSpLast style=3D'margin-left:42.0pt'><span
style=3D'font-size:10.5pt;font-family:Consolas'><o:p>&nbsp;</o:p></span></p=
>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
5)
Common API<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
<o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
Gilbert
Clark provided a short presentation on the SimpleBP (SBP) API is designed t=
o
provide a simple way to code applications which use DTN. In addition, a
tic-tac-toe game was demonstrated that was written using the SBP.=A0 The SB=
P code
is available here:<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
<o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
<a
href=3D"https://ion.ocp.ohiou.edu/content/sbpapi-065-alpha-1">https://ion.o=
cp.ohiou.edu/content/sbpapi-065-alpha-1</a><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
<o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
<a
href=3D"https://ion.ocp.ohiou.edu/content/sbp-api-documentation">https://io=
n.ocp.ohiou.edu/content/sbp-api-documentation</a><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
<o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
I will
see if the tic-tac-toe game could be released as well.<o:p></o:p></span></p=
>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
<o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
<o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.5pt;font-family:Consolas'>=
6)
DTNbone Discussions<o:p></o:p></span></p>

<p class=3DMsoListParagraphCxSpFirst style=3D'text-indent:-.25in;mso-list:l=
0 level1 lfo4'><![if !supportLists]><span
style=3D'font-size:10.5pt;font-family:Symbol'><span style=3D'mso-list:Ignor=
e'>=B7<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D'font-size:10.5pt;font-family:=
Consolas'>Ohio
University utilized work started by others (BBN?) and completed bundling
extensions for wireshark and was able to get the implementation into the la=
test
release.=A0 Thus, if you download the latest release of wireshark, you will=
 be
able to use this to debug bundles.<o:p></o:p></span></p>

<p class=3DMsoListParagraphCxSpMiddle style=3D'text-indent:-.25in;mso-list:=
l0 level1 lfo4'><![if !supportLists]><span
style=3D'font-size:10.5pt;font-family:Symbol'><span style=3D'mso-list:Ignor=
e'>=B7<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D'font-size:10.5pt;font-family:=
Consolas'>DTN
disconnection topology<o:p></o:p></span></p>

<p class=3DMsoListParagraphCxSpMiddle style=3D'margin-left:1.0in;text-inden=
t:-.25in;
mso-list:l0 level2 lfo4'><![if !supportLists]><span style=3D'font-size:10.5=
pt;
font-family:"Courier New"'><span style=3D'mso-list:Ignore'>o<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; </span></span></s=
pan><![endif]><span
style=3D'font-size:10.5pt;font-family:Consolas'>Both OU and GRC agreed that=
 we
need some permanently always accessible Disconnected Networks for network
management.=A0 It was decided that GRC and OU would put nearly identical ne=
twork
together, on running DTN2 and the other ION.<o:p></o:p></span></p>

<p class=3DMsoListParagraphCxSpMiddle style=3D'margin-left:1.0in;text-inden=
t:-.25in;
mso-list:l0 level2 lfo4'><![if !supportLists]><span style=3D'font-size:10.5=
pt;
font-family:"Courier New"'><span style=3D'mso-list:Ignore'>o<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; </span></span></s=
pan><![endif]><span
style=3D'font-size:10.5pt;font-family:Consolas'>Three base network types wh=
ere
identified<o:p></o:p></span></p>

<p class=3DMsoListParagraphCxSpMiddle style=3D'margin-left:1.5in;text-inden=
t:-.25in;
mso-list:l0 level3 lfo4'><![if !supportLists]><span style=3D'font-size:10.5=
pt;
font-family:Wingdings'><span style=3D'mso-list:Ignore'>=A7<span style=3D'fo=
nt:7.0pt "Times New Roman"'>&nbsp;
</span></span></span><![endif]><span style=3D'font-size:10.5pt;font-family:=
Consolas'>One
with the first bundle agent reachable in the order of minutes and the bundl=
e
agent behind the first reachable on the order of tens of minutes.<o:p></o:p=
></span></p>

<p class=3DMsoListParagraphCxSpMiddle style=3D'margin-left:1.5in;text-inden=
t:-.25in;
mso-list:l0 level3 lfo4'><![if !supportLists]><span style=3D'font-size:10.5=
pt;
font-family:Wingdings'><span style=3D'mso-list:Ignore'>=A7<span style=3D'fo=
nt:7.0pt "Times New Roman"'>&nbsp;
</span></span></span><![endif]><span style=3D'font-size:10.5pt;font-family:=
Consolas'>A
second with the first bundle agent reachable in the order of tens of minute=
s
and the bundle agent behind the first reachable on the order of minutes.<o:=
p></o:p></span></p>

<p class=3DMsoListParagraphCxSpMiddle style=3D'margin-left:1.5in;text-inden=
t:-.25in;
mso-list:l0 level3 lfo4'><![if !supportLists]><span style=3D'font-size:10.5=
pt;
font-family:Wingdings'><span style=3D'mso-list:Ignore'>=A7<span style=3D'fo=
nt:7.0pt "Times New Roman"'>&nbsp;
</span></span></span><![endif]><span style=3D'font-size:10.5pt;font-family:=
Consolas'>A
third reachable by multiple paths thereby testing dynamic routing.<o:p></o:=
p></span></p>

<p class=3DMsoListParagraphCxSpMiddle style=3D'margin-left:1.0in;text-inden=
t:-.25in;
mso-list:l0 level2 lfo4'><![if !supportLists]><span style=3D'font-size:10.5=
pt;
font-family:"Courier New"'><span style=3D'mso-list:Ignore'>o<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; </span></span></s=
pan><![endif]><span
style=3D'font-size:10.5pt;font-family:Consolas'>The conceptual network layo=
ut is
posted on the DTNRG wiki<o:p></o:p></span></p>

<p class=3DMsoListParagraphCxSpLast style=3D'margin-left:1.0in;text-indent:=
-.25in;
mso-list:l0 level2 lfo4'><![if !supportLists]><span style=3D'font-size:10.5=
pt;
font-family:"Courier New"'><span style=3D'mso-list:Ignore'>o<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; </span></span></s=
pan><![endif]><span
style=3D'font-size:10.5pt;font-family:Consolas'>OU and GRC will implement t=
hese
in virtual machines with the gateway portions and the network management
portions reachable via the Open Internet.<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size=
:10.0pt;
font-family:"Courier New"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size=
:10.0pt;
font-family:"Courier New"'>Submitted by Will Ivancic 01/12/2010<o:p></o:p><=
/span></p>

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

</div>

</body>

</html>

--_000_3A5AA67A8B120B48825BFFCF544385619480BD75F0NDJSSCC03ndcn_--

From: <[email-masked]>
To: <[email-masked]>
Date: Tue, 12 Jan 2010 09:39:33 +0000
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Cc: [email-masked]
Subject: Re: [dtn-interest] QoS in DTN

Hi all,

in a recent position paper, [1], we've discussed/proposed service differentiation techniques for DTNs. We've concluded that the service a user receives depends on the application running on top, since the application's "satisfaction" is what really matters and applications' requirements differ massively. We used Delivery Delay and Delivery Reliability as the ultimate service metrics. As Elwyn pointed, there's no way an end-user can define/specify delay-thresholds, or at least this would probably not scale. At the same time, however, a more globally defined system of rules, where bundle expirations and forwarding decisions are made based on the applications has better potential of achieving good performance in opportunistic connectivity nets.

Cheers,
Ioannis.

[1] http://personal.ee.surrey.ac.uk/Personal/I.Psaras/extremecom09-ipsaras.pdf

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Elwyn Davies [[email-masked]]
Sent: 05 January 2010 07:51
To: Ma Xuebin
Cc: dtn-interest
Subject: Re: [dtn-interest] QoS in DTN

Hi.

Measuring the delivery effectiveness of a DTN network is much discussed
in the literature on routing in opportunistic networks.  This paper
http://www.cs.umass.edu/~arun/papers/RAPID.pdf on the RAPID routing
protocol is a good start.  Delivery effectiveness is probably the best
measure of the 'QoS' of a DTN, but what exactly this means is a matter
of ongoing discussion.

As with conventional IP networks, there is no way that the end user can
seriously hope to specify the delay to be tolerated and have this
honored by the network.  The best that can be done is for the end
user/application to determine a time when the contents of a given
message is no longer useful and set this as the expiry time of the
bundle containing the data.  Actually DTN is more helpful in this than
conventional IP networks because ther is no way to control this expiry
time in IP (we try very hard to ignore time in IP networks!)

RFC 5050 in principle offers a small set of priorities that can be
applied to bundles.  As with IP, trying to apply these to user bundles
is probably impractical for many of the same reasons that are discussed
in the IP literature (authorization, priority escalation, DoS, etc.)

As you may gather, I am what might be described as a 'QoS Sceptic'.
Trying to persuade an end user that s/he has any sort of control over
the delivery of an individual packet/bundle is at best a fantasy and at
worst a cruel con trick.  This is primarily because in general the
network does not have much/any control knobs that can be adjusted to
affect this delivery. OTOH post-facto measurement of what happened and
doing statistical analysis is clearly possible and desirable.

Regards,
Elwyn Davies

Ma Xuebin wrote:
> Hi all,
>
> How to understand the QoS in DTN? We know the delay is an important
> factor to be considered in QoS , but which is tolerated in DTN. Does
> this mean that delay is not need considered in QoS of DTN? If so, then
> we focus on what kind of factors?
>
> 2010-01-05
> ------------------------------------------------------------------------
> Ma Xuebin
> ------------------------------------------------------------------------
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

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

Date: Mon, 11 Jan 2010 15:27:17 -0500
From: "Omar Y. Tahboub" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] The Second International Workshop on Concurrent Communication (ConCom 2010)

The Second International Workshop on Concurrent Communication (ConCom 2010)

		    In Conjunction with SAINT2010
			     Seoul, Korea
			  July 19 - 23, 2010
	    http://infonet.cse.kyutech.ac.jp/conf/saint10/

CALL FOR PAPER

* THEME OF THE WORKSHOP

The Second International Workshop on Concurrent Communication (ConCom
2010) focuses on the new networking paradigm that intends to revisit
two assumptions about concurrency used in classical networking-
pathway singularity and hop persistence. Classical architecture has
been designed to support single pathway between two
end-points. However, with the maturation of network topologies now
invites increased parallelism in communication. Parallel communication
can offer multi-faceted advantages such as order of magnitude
increased throughput, increased reliability and/or improved resource
utilization. Another design assumption of classical network is that
all hops must be available concurrently to establish an end-to-end
connectivity which we call hop-persistence. A number of research
paradigms ranging from aero-space networks, ad-hoc networks, sensor
networks now fundamentally struggling to overcome such
non-intermittency.

The first workshop of Concurrent Communication is aimed at bringing
together researchers who are trying to develop new network technology-
including architectural, protocol, and applications that explores and
shares experiences and insights in the relaxation of these two
classical notions of concurrency in networking.

We hope that this workshop will give helpful hints for the design,
operation and applications of the next generation concurrent
communication networking paradigm.
    
* TOPICS OF INTEREST

- Concurrent Communication Network Architectures 
  - Distributed Parallel Communication Networks
  - Multi-stream transport Networks 

- On-Demands Scheduling-based Communication in Concurrent
  Communication Networks
  - On-demand Scheduling-based Communication Networks Architectures 
  - On-demand Scheduling-based Communication Protocol Architectures 
  - On-demand Scheduling-based Routing Algorithms 
  - On-demand Scheduling-based Routing Protocols
  - On-demand Scheduling-based Data Transport Algorithms 
  - On-demand Scheduling-based Data Transport Protocols
  - On-demand Scheduling-based Application Protocols

- Intermittent Communication Network Architectures 
  - Space Communication Networks 
  - Disruption/Delay Tolerant Networks (DTNs)
  - Intermittently Connected Mobile Ad Hoc Networks (ICMAN)
  - Vehicular Networks (VNets)
  - Aerospace Networks (AeroNets)
  - Personal Area Networks (PANs)
  - Wireless Sensor Forwarding Networks 
  - Peer-to-Peer Content Distribution Networks CDN¢s
  - Dynamic Circuit Networks (DCNs) 

- On-Demand Scheduling-based Communication in Intermittent Networks
  - On-demand Scheduling-based Communication Networks Architectures 
  - On-demand Scheduling-based Communication Protocol Architectures 
  - On-demand Scheduling-based Routing Algorithms 
  - On-demand Scheduling-based Routing Protocols
  - On-demand Scheduling-based Data Transport Algorithms 
  - On-demand Scheduling-based Data Transport Protocols
  - On-demand Scheduling-based Application Protocols
    
* PAPERS AND AUTHOR'S KIT

Workshop papers should be within 4 pages, no extra page is allowed.
The Proceedings of the Symposium and the Workshops will be published,
in separated volumes, by the IEEE Computer Society Press. Please
follow the instruction on the web below where authors can find Page
Form and appropriate pointers for LaTeX Macros. Please visit SAINT
2010 Website (http://infonet.cse.kyutech.ac.jp/conf/saint10/) and
select `Information for Authors'.

* PAPER SUBMISSION

Papers should be submitted on-line no later than Feburary 28, 2010.
Papers should be sent to the Organizers and Program Committee of the
Workshop at concom-submit[atmark]ispl.jp. After a review process by
Organizers and Program Committee of the Workshop, authors of accepted
papers will be requested to send its final manuscript to IEEE-CS press
no later than April 30, 2010. So, authors are kindly requested to
submit papers as early as possible to facilitate a review process.
    
* IMPORTANT DATES

Workshop Paper Submission: Feburary 28, 2010
Workshop Paper Notification: March 31, 2010 
Workshop Final Manuscript: April 30, 2010 
Author registration due: TBD 
Workshop: July 19 - 23, 2010 (exact date is TBD) 

* REGISTRATION

It is the IEEE policy that accepted papers can be published only when
IEEE recognizes that at least ONE author has completed FULL
registration for SAINT Conference. So, authors will be requested to
register along with the final manuscript. SAINT Conference
Registration fees include a copy of the Conference proceedings, a copy
of the Workshop proceedings, and admission to the Conference and
Workshop sessions.

* NOTE
    
The date and length (a full or half day) of the Workshop will be
decided by SAINT2010 Organizing Committee taking account of the number
of submitted papers, and be announced on the SAINT2010 web. Please
also note that, according to the SAINT2010 Organizing Committee, the
Workshop is subject to cancellation if the number of submitted papers
is not sufficient.
    
* ORGANIZERS

- Mr. Omar Y. Tahboub, Kent State University, USA
- Prof. Javed I. Khan, Kent State University, USA
    
* PROGRAM COMMITTEE FOR PAPER REVIEW

- Dr. Ala Al-Fuqaha, West Michigan University Kalamazoo, USA
- Dr. Ali Abu-EI Humos, Jackson State University, USA
- Dr. Graciela Perera, Youngstown State University, USA
- Prof. Javed I. Khan, Kent State University, Kent, USA
- Dr. Muhammad Anan, Purdue University Calumet, USA
- Mr. Pedro Wightman, University of South Florida, USA
- Mr. Mohammad Ali Salahuddin, Western Michigan University, USA
- Mr. Mohammed Elbes, Western Michigan University, USA
- Mr. Ahmad Al-Ja'afreh, Western Michigan University, USA

-- 
Omar Y. Tahboub
PhD Candidate
Multimedia and Communication Networks Lab (Medianet)
Department of Computer Science 
Office:MSB 255
Office: 330-672-7825
Cellphone: 330-389-1064  
Url: http://www.cs.kent.edu/~otahboub
Kent State University
Kent, Ohio, 44242-0001

Date: Mon, 11 Jan 2010 17:45:35 +0100
From: Aline Carneiro Viana <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CFP: IEEE MASS 2010

*Apologies if you receive multiple copies*

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

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

   		     October 2010 - San Francisco, CA, USA
=================================================================================

IMPORTANT DATES:

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

SCOPE:

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

TOPICS OF INTEREST:

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

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

WORKSHOPS:

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

=================================================================================
GENERAL CO-CHAIRS

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

PROGRAM CO-CHAIRS

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

TPC SUB-AREA CHAIRS

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

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

- Algorithms and theory
Dong Xuan, Ohio State University

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

WORKSHOP CO-CHAIRS

Cedric Westphal, DoCoMo Labs
Christine Pepin, DoCoMo Labs

DEMO CHAIR

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

WEB CHAIR

Venkatesh Rajendran, Wionics

FINANCE AND REGISTRATION CHAIR

Zhen Jiang, West Chester University

PUBLICATION CHAIR

Dajin Wang, Montclair State University

PUBLICITY CHAIR

Aline Carneiro Viana, INRIA

LOCAL ARRANGEMENTS CO-CHAIRS

Kumar Viswanath, NTT Labs
Ignacio Solis, PARC

STEERING COMMITTEE CHAIR

Dharma P. Agrawal, University of Cincinnati

CHAIR OF IEEE TC ON DISTRIBUTED PROCESSING

Jie Wu, US National Science Foundation

CHAIR OF IEEE TC ON SIMULATION

Dave Cavalcanti, Phillips Research

Date: Sat, 9 Jan 2010 09:06:37 -0500
From: Rajesh Krishnan <[email-masked]>
To: xlwujunying <[email-masked]>
Cc: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] what about connectivity in DTN

Evolving graphs are a useful construct here, and have been used in the
DTN literature to extend graphs with a time dimension.

Best Regards,
Rajesh

2010/1/9 xlwujunying <[email-masked]>:
> Hi,
>
> Thank you very much for replies, the letter is much helpful for me to study
> the differences between traditional networks and DTNs.
>
> Our group has been study DTN for a while, and we felt that DTN is lack of
> some theory and mathematics support.
>
> We study traditional network on the basis of Graph Theory. all the terms in
> Graph Theory can be also used in Networks and there are no definitional
> differences, So are the algorithms.
>
>        But things do not go well when it comes to DTN, There are many
> differences between Graph and DTN. as you said, there may be a time
> dimension in DTNs. Topological adjacent can explain some type of DTNs, like
> Scheduled DTNs, but no MANETs. Also, if we define topological adjacent as
> there may be “connectivity” between two nodes at some time, then
> connectivity cannot be “computed” from topological adjacent since
> connectivity are needed first before we judge wether two nodes are
> topological adjacent.
>
>        In my opinion, we need to extend or redefine the terms of Network &
> Graph so that these terms can be used in DTN, and new algorithm and
> conclusion of (DT)Graph should be considered.
>
>        First of all, some basic terms of Graph should be extended.
>
>        What about we add “time dimension” in DTNs?
>
>
> --
> KLBNT(Key Lab of Beijing of Network Technology)
> BUAA(Beijing University of Aeronautics and Astronautics)
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>

Date: Sat, 9 Jan 2010 13:10:29 +0800 (CST)
From: xlwujunying <[email-masked]>
To: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] what about connectivity in DTN

------=_Part_25877_8178295.1263013829015
Content-Type: text/plain; charset=gbk
Content-Transfer-Encoding: base64

------=_Part_25877_8178295.1263013829015
Content-Type: text/html; charset=gbk
Content-Transfer-Encoding: base64

------=_Part_25877_8178295.1263013829015--

Date: Fri, 08 Jan 2010 17:03:50 +0000
From: Elwyn Davies <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: [dtn-interest] [Fwd: review of draft-irtf-dtnrg-bundle-security-12 (was Re: [IRSG] DTNRG review assignments)]

This is a multi-part message in MIME format.
--------------090700090105070700040803
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi.

This is the IRSG review of the Bundke Security protocol by Andrei Gurtov.

Please take a look at the comments and send your views to the list asap.

Authors:  Please consider your responses and think about a new version
if appropriate.

Let's set a deadline of Monday 18th January for list comments please!

Regards,
Elwyn

-------- Original Message --------
Subject:     review of draft-irtf-dtnrg-bundle-security-12 (was Re:
[IRSG] DTNRG review assignments)
Date:     Thu, 31 Dec 2009 17:12:47 +0200
From:     Andrei Gurtov <[email-masked]>
To:     Elwyn Davies <[email-masked]>
CC:     Aaron Falk <[email-masked]>, Stephen Farrell
<[email-masked]>
References:     <[email-masked]> <[email-masked]>
<[email-masked]> <[email-masked]>
<[email-masked]>

Hi Elwyn,

I've read the document through several times and I think it's ready to
publish. The document is very well written and apparently has been
already reviewed thoroughly by the RG since the text is quite clear and
generally bug-free. The document structure is intuitive and proposed
solutions appear very reasonable. Having a generic ASB in other block
descriptions seems neat (could be called a common header in other
terminology).

Some security experts might want to see an attack model to be explicitly
stated in the beginning of the document. I.e. it's assumed that attacker
could eavesdrop or modify the messages in transit but not directly
compromise DTN nodes, etc.

The presently defined 4 cryptographic suits include traditional RSA and
SHA algorithms with larger key sizes. However those take plenty of space
 and processing time and ECC is better almost an order of magnitude both
in space and processing time. This might be important for resource- and
bandwidth- restricted environments where DTNs could operate. It would be
good to see some discussion on this issue, and why not make ECC the
default suites. There are some IPR issues perhaps, but at least latest
openssl library includes free open-source ecc code.

In fig 2 and other similar ones there is no numbering of bits
traditionally present in RFCs. It would be perhaps a good idea to
include those, especially since the bit numbering could be from right to
left in some cases (if I understood correctly from other examples).

Fig 6 and 7 look exactly the same, are both of them needed?

Has someone actually implemented this specification? It would be nice to
have a summary of their experiences/pointers to the code, or is this
planned for a separate document?

Some minor nits and typos are also marked on the attached PDF.

Best regards
Andrei

E

--------------090700090105070700040803
Content-Type: application/pdf; name="draft-irtf-dtnrg-bundle-security-12.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="draft-irtf-dtnrg-bundle-security-12.pdf"

--------------090700090105070700040803--

Date: Fri, 8 Jan 2010 17:20:05 +0100
From: rerngvit yang <[email-masked]>
To: [email-masked]
Cc: Avri Doria <[email-masked]>, [email-masked], [email-masked], Bjorn Pehrson <[email-masked]>, =?UTF-8?Q?Herv=C3=A9_Ntareme?= <[email-masked]>
Subject: [dtn-interest] New DTN implementation available on Android Platform

--0016e6dab100830fa8047ca98ff8
Content-Type: text/plain; charset=UTF-8

Hello All,
        We would like to inform you about new DTN implementation available
in Opensource license. We made the implementation on Android platform by
porting code concerning the Bundle Protocol (RFC5050) from DTN2 software
version 2.6. In addition to the implementation we also provided
documentations such as user manual, installation guide, Javadoc, and
technical demonstration video. This implementation is one of the
deliverables of the Bytewalla project.  Bytewalla project is a project from
Communication System Design(CSD) course in  Telecommunication Systems
Laboratory (TSLab), Royal Institute of Technology, Sweden.

More information about Bytewalla including the source code release can be
found at [http://www.tslab.ssvl.kth.se/csd/projects/092106/]
More information about CSD can be found at [
http://www.tslab.ssvl.kth.se/csd/]

-- 
Best Regards,
Rerngvit Yanggratoke

--0016e6dab100830fa8047ca98ff8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello All,<div>=C2=A0=C2=A0 =C2=A0 =C2=A0<font class=3D"Apple-style-span" f=
ace=3D"Arial, Helvetica, sans-serif" size=3D"3"><span class=3D"Apple-style-=
span" style=3D"font-size: 12px;">=C2=A0</span></font><span class=3D"Apple-s=
tyle-span" style=3D"font-family: Arial, Helvetica, sans-serif; font-size: 1=
2px; "><span class=3D"Apple-style-span" style=3D"font-family: arial; font-s=
ize: small; ">=C2=A0<span class=3D"Apple-style-span" style=3D"font-family: =
Arial, Helvetica, sans-serif; font-size: 12px; ">We would like to inform yo=
u about new DTN implementation available in Opensource license. We made the=
 implementation on Android platform by porting code concerning the Bundle P=
rotocol (RFC5050) from</span>=C2=A0DTN2 software version 2.6.=C2=A0In addit=
ion to the implementation we also provided documentations such as user manu=
al, installation guide, Javadoc, and technical demonstration video.=C2=A0Th=
is implementation is one of the deliverables of the Bytewalla project.=C2=
=A0=C2=A0Bytewalla project is a project from Communication System Design(CS=
D) course in=C2=A0=C2=A0Telecommunication Systems Laboratory (TSLab), Royal=
 Institute of Technology, Sweden.=C2=A0</span></span></div>
<div><br></div><div>More information about Bytewalla including the source c=
ode release can be found at [<a href=3D"http://www.tslab.ssvl.kth.se/csd/pr=
ojects/092106/">http://www.tslab.ssvl.kth.se/csd/projects/092106/</a>]</div=
>
<div>More information about CSD can be found at [<a href=3D"http://www.tsla=
b.ssvl.kth.se/csd/">http://www.tslab.ssvl.kth.se/csd/</a>]</div><div><br></=
div><div>-- <br>Best Regards,<br>Rerngvit Yanggratoke<br>
</div>

--0016e6dab100830fa8047ca98ff8--

Date: Thu, 07 Jan 2010 10:33:03 +0000
From: Stephen Farrell <[email-masked]>
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] LTP CL

Hi Scott,

Fair enough, implementation issues are relevant.

First, I'd note that, for me at least, the fact that the
DTN2 UDPCL only handles one bundle per UDP packet has been
a problem - I had to hack in a way to handle larger bundles
in order to use it, albeit that that was for testing.
However, the one bundle-per-UDP packet limitation essentially
makes the UDPCL unusable for many applications. I think that
the restriction you're suggesting for the LTPCL would have
the same effect - it will limit the utility of the CL to
only a few applications, that deal with smaller bundles.

Your description below also ignores the additional, and
quite serious, complexity implicit in requiring that the
BPA pro-actively fragment bundles into LTP segment-sized
chunks.

- LTP segment sizes may, in principle, be variable, over
  time or dependent on the peer. You are pushing a
  requirement for knowledge of that outside of the LTP
  code.
- If LTP extensions (e.g. those in RFC 5327 or those I
  defined for the LTP-T work I did) are added by the
  LTP engine then the BPA's fragmentation calculations
  will be wrong, unless you have some horrendous
  interface where the BPA can query the LTP engine
  about how much overhead its going to add to each
  LTP segment.
- Specifically, the LTP cookie extension in rfc 5327
  if supported, can change length, (get longer)
  *during* an LTP session. The BPA just can't handle
  that before handling the bundles to the LTP engine.

That all implies that your one bundle-per-green-segment
constraint requires an extremely complex interface to
fully support LTP. It also rules out any future
extensibility at the LTP level unless you also modify
the proactive fragmentation code in the BPA.

As another example, for a give red-size you can only
fragment (in the BPA code) after you know the exact size
of all the LTP headers and extensions that are to be
included in the segment. ION currently uses short
(16 bit) engine ids if I recall. If you were ever to
change ION to use longer engine ids then you'd also
have to change the corresponding code in the BPA.

Your description below is also very dependent on how
the LTP implementation is designed. LTPlib, for all
its openly-admitted sins, will I think, handle all
these cases just fine, with no new code required.
That may not be true for ION's LTP code (I've not
looked), but designing the protocol spec so tightly
around a specific implementation is not, I think,
the way to do this.

For example, as mentioned above ION only currently
supports short LTP engine ids, so I had to add
code to LTPlib (search for "ion_mode") to only
produce short identifiers when we did the interop.
That's ok-ish, but I don't think you'd argue that
we shouldn't have used SDNVs for those fields in
the LTP protocol. I think your argument here is
essentially equivalent to saying that LTP should
be limited to 16 bit identifiers because that's
how it would be easiest for ION.

Towards the end below, you say that there's no
additional functionality with my approach. I hope
you'll concede that my approach does allow for the
use of LTP extensions, whereas yours doesn't. If
so, then any additional functionality offered by
those LTP extensions is relevant. As a concrete
example, RFC 5327 defines some security extensions.

I see that you do acknowledge that my approach
will be more efficient in terms of requiring fewer
overhead bytes, and fair enough that CBHE might
minimise the additional but unavoidable overhead
in your approach. But your approach also means
that any BP extension blocks that are added later
would also add to that inefficiency. The BAB in
particular, which I think you may want to use,
is likely to be large enough to be a concern.

Finally, I just disagree that your approach is
less complex in general, which is what the spec
should be addressing. It may be simpler for the
case of ION which is limited to ~64K bundles and
can support ~64K LTP segments, uses CBHE, doesn't
support LTP extensions, and doesn't really envisage
using BP extension blocks (except maybe BAB). For
LTPlib, with LTP extensions supported, with DTN2
with various extension blocks supported, your
approach is, I think, far more complex. (As it
happens one of our students, (Darragh) is doing the
DTN2/LTPlib integration now, so this is not a
theoretical concern.)

Its not that there's anything wrong with ION, (there
isn't) but developing the protocol spec so tightly
based on the reasonable implementation decisions
you've made for ION is not reasonable.

Cheers,
Stephen.

Burleigh, Scott C (313B) wrote:
> Okay, let me approach this a different way.  Let's look at the implementation implications.
> 
> Let's say I'm an LTP convergence layer adapter that receives the content of a green segment for session X, block offset Y.  And let's also say that I'm running on a BP node that is in punctuated contact with my neighbors, and there's no way to guarantee that transmission from my neighbor (the sender of session X) won't be suspended while one or more sessions are in progress -- i.e., I don't know whether the next green segment for session X will arrive a few milliseconds from now or several hours or days from now.
> 
> Suppose the rule is that every green segment always contains exactly one complete bundle, as described in the draft.  Here's how I process this event:
> 
> 1.   I pass a pointer to the segment content, along with its length, to the bundle protocol agent for processing.
> 
> Okay, I'm all done.  The BP implementation parses this data and processes it as a bundle in the standard way, per RFC 5050, but as an LTP CLA I've got no more to do.
> 
> Alternatively, suppose the rule is that every LTP block contains exactly one complete bundle.  (Not as powerful as what's in the draft, since I can't do aggregation of multiple bundles in a single block to control acknowledgment traffic volume, but it's simple.)  Here's how I process this event:
> 
> 1.   In the special case where the segment is EOB and Y = 0, the processing is exactly the same as above.  The whole block is green and it's just one segment, so I've got the whole bundle.
> 
> 2.   There's another special case where the segment is EOB and Y = the length of the block's red-part and the entire red-part has been received.  In this case, I've now got the whole block, hence the whole bundle; same processing.
> 
> But in order to know the length of the red-part and whether or not I've got it all, I have to look up session X in my linked list of currently active blocks.  That means I need to create an entry in that list when I get the first red-part segment for X.
> 
> Fair enough, I need to do that for red-part reassembly anyway.  But if the EOR segment wasn't also the EOB I need to hold onto that entry even after I've reassembled the red-part -- because I'm expecting some green segments.
> 
> Obviously as soon as I have received all the green segments and reconstructed the green-part of the block I can pass the bundle up to BP and delete the block list entry.  But suppose none of those green segments ever arrive (which is entirely possible; they're not retransmitted).  Now I've got a block list entry that never gets deleted, a memory leak, unless I use some sort of time-driven procedure to get rid of stale block entries.  How do I know how long to wait, though, since it may be that the green segments will arrive ten minutes from now, or tomorrow?  If my timer is too conservative, I'm wasting memory; if it's too aggressive, I'm dropping bundles.
> 
> But let's continue.
> 
> 3.   If the segment is EOB and Y is equal to the block's red-part length but the red-part isn't yet completely received (maybe a missing segment is being retransmitted), then I've got to stash the segment content in my block entry somewhere and wait for the completion of red-part reception.  Arrival of the last missing red-part segment will trigger delivery of the entire block and deletion of the block list entry.
> 
> 4.   If the segment is EOB and the red-part is completely received but Y isn't equal to the block's red-part length, then this segment isn't the entire green-part.  Have all the other green segments been received?  I'd better have saved them all in a linked list of green segments in the block entry, otherwise I've thrown away part of the bundle.  I can walk that linked list and see if there are any gaps other than the one starting at offset Y.  If there aren't, great, I've now got the whole bundle and can deliver it and delete the block list entry.  But if there are gaps, what do I do?
> 
> If I'm absolutely certain that segments can't arrive out of transmission order, then I can complete the processing of this block: if I parse the bundle far enough to know that the first gap is after the start of the payload content -- and I know there's no bundle authentication -- then I can tell the sender to reactively fragment the bundle at the offset that is the start of the first gap (which will cause re-forwarding and retransmission of the remainder of the bundle payload, possibly quite a lot of data) and deliver to BP the reactively truncated bundle that I've received, and ditch the rest; or I can simply ditch the entire bundle.  In either case I can now delete the block list entry.
> 
> But suppose it's remotely possible for green segments to arrive out of transmission order (e.g., they're being carried by UDP).  Now it's possible that the gaps will be filled by green segments that arrive in the future, so I can wait for them.  But I can't wait forever, as that would again be a memory leak; I need some sort of time-driven procedure to get rid of stale block entries.  How do I know how long to wait, since it may be that the green segments will arrive ten minutes from now, or tomorrow?
> 
> 5.   If the segment is not EOB, I know need to walk my green-segments linked list for this block and insert this segment's contents into the appropriate gap.  Now, is the red-part is completely received?  If so, is the green-part completely received?  If so, deliver the bundle and and delete the block entry; if not, I've got to make the same decision as in #4.  If the red-part is not yet completely received, I've got the same case as #3.
> 
> Okay, that's not too bad.  Now let's look at a slightly different design: every LTP block contains exactly N complete bundles, N >= 1, and (to simplify things) each bundle in the block has to be entirely red or entirely green, i.e., the first byte of the green-part is guaranteed to be the first byte of a bundle.
> 
> 1.   In the special case where the segment is EOB and Y = 0, things are easy: I just parse all the bundles out of the segment and pass them up to BP.
> 
> 2.   In the case where the segment is EOB and Y = the length of the block's red-part (whether the red-part is fully received or not), I do the same; all the green bundles have arrived.  But again I have to look up session X in my linked list of currently active blocks to know the length of the block's red-part, and I need to retain that block list entry even if the block's red-part has been fully received and all of its bundles delivered, because I need to know the red-part length in order to process the green-part segments.  Of course, I've got the same block list entry purge problem as above.
> 
> But hang on: it's possible that all the green segments arrived before any of the red segments (they all needed to be retransmitted), so I may not need to retain the block list entry after red-part completion after all.  So I also I need to remember what happened with the block's green segments (if any) in order to process the red segments properly.
> 
> 3.   If the segment is EOB and Y isn't equal to the block's red-part length, then I've got case #4 from the earlier design again (whether the red-part is fully received or not).  If there are no gaps in the green-part segment list, I'm back to case #2.  If there are gaps and it's possible for green segments to arrive out of order, then I've got to wait for the missing segments as above.  If there are gaps and I know the segments arrive in transmission order, then I can parse out and deliver to BP the complete bundles that occupy all segments up to the start of the first gap, and I could conceivably even reactively fragment the bundle whose payload extends into that gap, but I have to discard everything else: I've got no way to parse out any more bundles from the rest of the green-part, so they're all lost.  (Unless, of course, I do something like precede every bundle in the block with a sync marker and re-sync after each gap, which would add a further increment of complexit
y and some additional transmission overhead.)
> 
> 4.   If the segment is not EOB, I again walk my green-segments linked list for this block and insert this segment's contents into the appropriate gap.  Now, is the green-part completely received?  If so, I parse all the bundles out of the concatenated green-part segments and pass them up to BP.  If not, I'm done for now; I'm back to the same block list entry purge problem.
> 
> Now let's combine the two: every LTP block contains exactly N complete bundles, N >= 1, to satisfy my requirement to enable aggregation, but one of the bundles in the block can straddle the red/green boundary, to satisfy your requirement for partially-red bundle transmission.
> 
> I am getting tired of typing, so I won't try to describe all the processing logic in this design; I think it's intuitively clear that its complexity is approximately the union of the complexities of the previous two.
> 
> Now, I certainly won't argue that complexity itself is always a bad thing.  Simple designs do tend to be safer and cheaper, but complexity is surely justified if it provides significantly enhanced functionality or performance.
> 
> In this case, I don't see that.
> 
> The more complex designs don't provide any additional functionality, since bundle fragmentation combine with the simple design can transmit exactly the same user data units with exactly the same quality of service.
> 
> It's possible that the more complex designs would reduce transmission overhead somewhat by causing fewer BP primary and extension blocks to be transmitted.  But I doubt that this reduction would be very dramatic, especially if you were using CBHE in the bundles.  In any case, this seems like a pretty thin rationale for inflicting all this pain on the convergence-layer software developer and maintainer -- especially since the complex designs rest on timer interval estimation that in the general case cannot be done accurately, and gaps in the green-part will result in the ditching of complete, fully-received (but unrecognizable) bundles if the green-part can be the aggregation of multiple bundles.
> 
> Scott
> ________________________________________
> From: Stephen Farrell [[email-masked]]
> Sent: Wednesday, January 06, 2010 10:57 AM
> To: Burleigh, Scott C (313B)
> Cc: dtn-interest
> Subject: Re: LTP CL
> 
> Burleigh, Scott C (313B) wrote:
>>> -----Original Message-----
>>> From: Stephen Farrell [mailto:[email-masked]]
>>> Sent: Wednesday, January 06, 2010 10:26 AM
>>> To: Burleigh, Scott C (313B)
>>> Cc: dtn-interest
>>> Subject: Re: LTP CL
>>>
>>>
>>>
>>> Burleigh, Scott C (313B) wrote:
>>>
>>>> Okay, then, I think we've got no issue.  All I'm saying in
>>>> the LTPCL draft is that the content of each green-part
>>>> segment needs to be a complete bundle,
>>> I think that's exactly where we do have an issue. I'm
>>> advocating that the LTP-CL not include that requirement
>>> since it limits the use of this LTP-CL spec for BP/LTP to
>>> cases with small bundles so that each LTP segment can be
>>> as big as a bundle. (Actually a little bigger of course.)
>> Stephen, why did you delete the context?
> 
> Sorry if that affected the message. I was trying to highlight
> where we're disagreeing.
> 
>> '> Except that you can't do *anything* with a fragment of a bundle.  You can do things with a bundle that is "a fragment", i.e., a complete bundle whose payload is a portion of the payload of some predecessor bundle.  But you can't do any more with an incomplete bundle than you can with an incomplete IP packet.
>>
>> Fair enough on the terminology, what I meant was that the receiver could forward a reactively fragmented bundle based on the segments received. (Which was the entire point of reactive fragmentation wasn't it?)'
>>
>> A truncated or shredded bundle is useless.
> 
> Isn't handling such things the essence of reactive
> fragmentation? (Which is independent of any particular
> CL of course.)
> 
> And specific to LTP, wasn't handling truncated LTP blocks
> with the interesting bytes at the start exactly the
> justification for the red/green mechanism in the
> first place?
> 
>> There is zero utility in drawing the red/green boundary
>> in an LTP block in the middle of a bundle payload.
> 
> Even if I accepted that (which I don't really), all that would follow
> would be that the red/green boundary MUST be on a bundle boundary.
> Requiring that a full bundle fit with one green LTP segment does not
> follow at all.
> 
>> On the other hand, bundle fragmentation and reassembly solves
>> the problem of sending arbitrarily large bundles via LTP,
>> and it does so in a way that is already well documented in
>> RFC 5050, so the constraint on bundle encapsulation in green
>> segments doesn't preclude any functionality whatsoever.
>> I don't understand why you're arguing otherwise.
> 
> I'm arguing otherwise since I think limiting the utility of the LTPCL
> to cases where bundles and LTP segments are the same size (or where
> proactive fragmentation in the BP "layer" is otherwise required) is
> not a good design.
> 
> There're also fewer overhead bytes with my approach. Yours requires
> each green LTP segment to carry a bundle primary block (and maybe
> BAB or other blocks). Mine doesn't, since having LTP fragment the
> bundle/block is more efficient than the BP fragmenting the bundle
> and then passing each (fragmented) bundle with an additional LTP
> segment overhead. (I've not done the math however to see what the
> savings would be with CBHE though.)
> 
> Stephen.
> 
> PS: The term "block" is confusing here isn't it? "Block" is used
> for both the extensibility mechanism for the BP and the name of
> the payload bytes for LTP.
> 
>> Scott
> 

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Wed, 6 Jan 2010 21:52:44 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] LTP CL

Okay, let me approach this a different way.  Let's look at the implementation implications.

Let's say I'm an LTP convergence layer adapter that receives the content of a green segment for session X, block offset Y.  And let's also say that I'm running on a BP node that is in punctuated contact with my neighbors, and there's no way to guarantee that transmission from my neighbor (the sender of session X) won't be suspended while one or more sessions are in progress -- i.e., I don't know whether the next green segment for session X will arrive a few milliseconds from now or several hours or days from now.

Suppose the rule is that every green segment always contains exactly one complete bundle, as described in the draft.  Here's how I process this event:

1.   I pass a pointer to the segment content, along with its length, to the bundle protocol agent for processing.

Okay, I'm all done.  The BP implementation parses this data and processes it as a bundle in the standard way, per RFC 5050, but as an LTP CLA I've got no more to do.

Alternatively, suppose the rule is that every LTP block contains exactly one complete bundle.  (Not as powerful as what's in the draft, since I can't do aggregation of multiple bundles in a single block to control acknowledgment traffic volume, but it's simple.)  Here's how I process this event:

1.   In the special case where the segment is EOB and Y = 0, the processing is exactly the same as above.  The whole block is green and it's just one segment, so I've got the whole bundle.

2.   There's another special case where the segment is EOB and Y = the length of the block's red-part and the entire red-part has been received.  In this case, I've now got the whole block, hence the whole bundle; same processing.

But in order to know the length of the red-part and whether or not I've got it all, I have to look up session X in my linked list of currently active blocks.  That means I need to create an entry in that list when I get the first red-part segment for X.

Fair enough, I need to do that for red-part reassembly anyway.  But if the EOR segment wasn't also the EOB I need to hold onto that entry even after I've reassembled the red-part -- because I'm expecting some green segments.

Obviously as soon as I have received all the green segments and reconstructed the green-part of the block I can pass the bundle up to BP and delete the block list entry.  But suppose none of those green segments ever arrive (which is entirely possible; they're not retransmitted).  Now I've got a block list entry that never gets deleted, a memory leak, unless I use some sort of time-driven procedure to get rid of stale block entries.  How do I know how long to wait, though, since it may be that the green segments will arrive ten minutes from now, or tomorrow?  If my timer is too conservative, I'm wasting memory; if it's too aggressive, I'm dropping bundles.

But let's continue.

3.   If the segment is EOB and Y is equal to the block's red-part length but the red-part isn't yet completely received (maybe a missing segment is being retransmitted), then I've got to stash the segment content in my block entry somewhere and wait for the completion of red-part reception.  Arrival of the last missing red-part segment will trigger delivery of the entire block and deletion of the block list entry.

4.   If the segment is EOB and the red-part is completely received but Y isn't equal to the block's red-part length, then this segment isn't the entire green-part.  Have all the other green segments been received?  I'd better have saved them all in a linked list of green segments in the block entry, otherwise I've thrown away part of the bundle.  I can walk that linked list and see if there are any gaps other than the one starting at offset Y.  If there aren't, great, I've now got the whole bundle and can deliver it and delete the block list entry.  But if there are gaps, what do I do?

If I'm absolutely certain that segments can't arrive out of transmission order, then I can complete the processing of this block: if I parse the bundle far enough to know that the first gap is after the start of the payload content -- and I know there's no bundle authentication -- then I can tell the sender to reactively fragment the bundle at the offset that is the start of the first gap (which will cause re-forwarding and retransmission of the remainder of the bundle payload, possibly quite a lot of data) and deliver to BP the reactively truncated bundle that I've received, and ditch the rest; or I can simply ditch the entire bundle.  In either case I can now delete the block list entry.

But suppose it's remotely possible for green segments to arrive out of transmission order (e.g., they're being carried by UDP).  Now it's possible that the gaps will be filled by green segments that arrive in the future, so I can wait for them.  But I can't wait forever, as that would again be a memory leak; I need some sort of time-driven procedure to get rid of stale block entries.  How do I know how long to wait, since it may be that the green segments will arrive ten minutes from now, or tomorrow?

5.   If the segment is not EOB, I know need to walk my green-segments linked list for this block and insert this segment's contents into the appropriate gap.  Now, is the red-part is completely received?  If so, is the green-part completely received?  If so, deliver the bundle and and delete the block entry; if not, I've got to make the same decision as in #4.  If the red-part is not yet completely received, I've got the same case as #3.

Okay, that's not too bad.  Now let's look at a slightly different design: every LTP block contains exactly N complete bundles, N >= 1, and (to simplify things) each bundle in the block has to be entirely red or entirely green, i.e., the first byte of the green-part is guaranteed to be the first byte of a bundle.

1.   In the special case where the segment is EOB and Y = 0, things are easy: I just parse all the bundles out of the segment and pass them up to BP.

2.   In the case where the segment is EOB and Y = the length of the block's red-part (whether the red-part is fully received or not), I do the same; all the green bundles have arrived.  But again I have to look up session X in my linked list of currently active blocks to know the length of the block's red-part, and I need to retain that block list entry even if the block's red-part has been fully received and all of its bundles delivered, because I need to know the red-part length in order to process the green-part segments.  Of course, I've got the same block list entry purge problem as above.

But hang on: it's possible that all the green segments arrived before any of the red segments (they all needed to be retransmitted), so I may not need to retain the block list entry after red-part completion after all.  So I also I need to remember what happened with the block's green segments (if any) in order to process the red segments properly.

3.   If the segment is EOB and Y isn't equal to the block's red-part length, then I've got case #4 from the earlier design again (whether the red-part is fully received or not).  If there are no gaps in the green-part segment list, I'm back to case #2.  If there are gaps and it's possible for green segments to arrive out of order, then I've got to wait for the missing segments as above.  If there are gaps and I know the segments arrive in transmission order, then I can parse out and deliver to BP the complete bundles that occupy all segments up to the start of the first gap, and I could conceivably even reactively fragment the bundle whose payload extends into that gap, but I have to discard everything else: I've got no way to parse out any more bundles from the rest of the green-part, so they're all lost.  (Unless, of course, I do something like precede every bundle in the block with a sync marker and re-sync after each gap, which would add a further increment of complexity and some additional transmission overhead.)

4.   If the segment is not EOB, I again walk my green-segments linked list for this block and insert this segment's contents into the appropriate gap.  Now, is the green-part completely received?  If so, I parse all the bundles out of the concatenated green-part segments and pass them up to BP.  If not, I'm done for now; I'm back to the same block list entry purge problem.

Now let's combine the two: every LTP block contains exactly N complete bundles, N >= 1, to satisfy my requirement to enable aggregation, but one of the bundles in the block can straddle the red/green boundary, to satisfy your requirement for partially-red bundle transmission.

I am getting tired of typing, so I won't try to describe all the processing logic in this design; I think it's intuitively clear that its complexity is approximately the union of the complexities of the previous two.

Now, I certainly won't argue that complexity itself is always a bad thing.  Simple designs do tend to be safer and cheaper, but complexity is surely justified if it provides significantly enhanced functionality or performance.

In this case, I don't see that.

The more complex designs don't provide any additional functionality, since bundle fragmentation combine with the simple design can transmit exactly the same user data units with exactly the same quality of service.

It's possible that the more complex designs would reduce transmission overhead somewhat by causing fewer BP primary and extension blocks to be transmitted.  But I doubt that this reduction would be very dramatic, especially if you were using CBHE in the bundles.  In any case, this seems like a pretty thin rationale for inflicting all this pain on the convergence-layer software developer and maintainer -- especially since the complex designs rest on timer interval estimation that in the general case cannot be done accurately, and gaps in the green-part will result in the ditching of complete, fully-received (but unrecognizable) bundles if the green-part can be the aggregation of multiple bundles.

Scott
________________________________________
From: Stephen Farrell [[email-masked]]
Sent: Wednesday, January 06, 2010 10:57 AM
To: Burleigh, Scott C (313B)
Cc: dtn-interest
Subject: Re: LTP CL

Burleigh, Scott C (313B) wrote:
>> -----Original Message-----
>> From: Stephen Farrell [mailto:[email-masked]]
>> Sent: Wednesday, January 06, 2010 10:26 AM
>> To: Burleigh, Scott C (313B)
>> Cc: dtn-interest
>> Subject: Re: LTP CL
>>
>>
>>
>> Burleigh, Scott C (313B) wrote:
>>
>>> Okay, then, I think we've got no issue.  All I'm saying in
>>> the LTPCL draft is that the content of each green-part
>>> segment needs to be a complete bundle,
>> I think that's exactly where we do have an issue. I'm
>> advocating that the LTP-CL not include that requirement
>> since it limits the use of this LTP-CL spec for BP/LTP to
>> cases with small bundles so that each LTP segment can be
>> as big as a bundle. (Actually a little bigger of course.)
>
> Stephen, why did you delete the context?

Sorry if that affected the message. I was trying to highlight
where we're disagreeing.

> '> Except that you can't do *anything* with a fragment of a bundle.  You can do things with a bundle that is "a fragment", i.e., a complete bundle whose payload is a portion of the payload of some predecessor bundle.  But you can't do any more with an incomplete bundle than you can with an incomplete IP packet.
>
> Fair enough on the terminology, what I meant was that the receiver could forward a reactively fragmented bundle based on the segments received. (Which was the entire point of reactive fragmentation wasn't it?)'
>
> A truncated or shredded bundle is useless.

Isn't handling such things the essence of reactive
fragmentation? (Which is independent of any particular
CL of course.)

And specific to LTP, wasn't handling truncated LTP blocks
with the interesting bytes at the start exactly the
justification for the red/green mechanism in the
first place?

> There is zero utility in drawing the red/green boundary
> in an LTP block in the middle of a bundle payload.

Even if I accepted that (which I don't really), all that would follow
would be that the red/green boundary MUST be on a bundle boundary.
Requiring that a full bundle fit with one green LTP segment does not
follow at all.

> On the other hand, bundle fragmentation and reassembly solves
> the problem of sending arbitrarily large bundles via LTP,
> and it does so in a way that is already well documented in
> RFC 5050, so the constraint on bundle encapsulation in green
> segments doesn't preclude any functionality whatsoever.
> I don't understand why you're arguing otherwise.

I'm arguing otherwise since I think limiting the utility of the LTPCL
to cases where bundles and LTP segments are the same size (or where
proactive fragmentation in the BP "layer" is otherwise required) is
not a good design.

There're also fewer overhead bytes with my approach. Yours requires
each green LTP segment to carry a bundle primary block (and maybe
BAB or other blocks). Mine doesn't, since having LTP fragment the
bundle/block is more efficient than the BP fragmenting the bundle
and then passing each (fragmented) bundle with an additional LTP
segment overhead. (I've not done the math however to see what the
savings would be with CBHE though.)

Stephen.

PS: The term "block" is confusing here isn't it? "Block" is used
for both the extensibility mechanism for the BP and the name of
the payload bytes for LTP.

>
> Scott

Date: Wed, 06 Jan 2010 18:57:44 +0000
From: Stephen Farrell <[email-masked]>
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] LTP CL

Burleigh, Scott C (313B) wrote:
>> -----Original Message-----
>> From: Stephen Farrell [mailto:[email-masked]]
>> Sent: Wednesday, January 06, 2010 10:26 AM
>> To: Burleigh, Scott C (313B)
>> Cc: dtn-interest
>> Subject: Re: LTP CL
>>
>>
>>
>> Burleigh, Scott C (313B) wrote:
>>
>>> Okay, then, I think we've got no issue.  All I'm saying in
>>> the LTPCL draft is that the content of each green-part
>>> segment needs to be a complete bundle,
>> I think that's exactly where we do have an issue. I'm
>> advocating that the LTP-CL not include that requirement
>> since it limits the use of this LTP-CL spec for BP/LTP to
>> cases with small bundles so that each LTP segment can be
>> as big as a bundle. (Actually a little bigger of course.)
> 
> Stephen, why did you delete the context?

Sorry if that affected the message. I was trying to highlight
where we're disagreeing.

> '> Except that you can't do *anything* with a fragment of a bundle.  You can do things with a bundle that is "a fragment", i.e., a complete bundle whose payload is a portion of the payload of some predecessor bundle.  But you can't do any more with an incomplete bundle than you can with an incomplete IP packet.
> 
> Fair enough on the terminology, what I meant was that the receiver could forward a reactively fragmented bundle based on the segments received. (Which was the entire point of reactive fragmentation wasn't it?)'
> 
> A truncated or shredded bundle is useless.  

Isn't handling such things the essence of reactive
fragmentation? (Which is independent of any particular
CL of course.)

And specific to LTP, wasn't handling truncated LTP blocks
with the interesting bytes at the start exactly the
justification for the red/green mechanism in the
first place?

> There is zero utility in drawing the red/green boundary
> in an LTP block in the middle of a bundle payload.

Even if I accepted that (which I don't really), all that would follow
would be that the red/green boundary MUST be on a bundle boundary.
Requiring that a full bundle fit with one green LTP segment does not
follow at all.

> On the other hand, bundle fragmentation and reassembly solves 
> the problem of sending arbitrarily large bundles via LTP,
> and it does so in a way that is already well documented in
> RFC 5050, so the constraint on bundle encapsulation in green
> segments doesn't preclude any functionality whatsoever.
> I don't understand why you're arguing otherwise.

I'm arguing otherwise since I think limiting the utility of the LTPCL
to cases where bundles and LTP segments are the same size (or where
proactive fragmentation in the BP "layer" is otherwise required) is
not a good design.

There're also fewer overhead bytes with my approach. Yours requires
each green LTP segment to carry a bundle primary block (and maybe
BAB or other blocks). Mine doesn't, since having LTP fragment the
bundle/block is more efficient than the BP fragmenting the bundle
and then passing each (fragmented) bundle with an additional LTP
segment overhead. (I've not done the math however to see what the
savings would be with CBHE though.)

Stephen.

PS: The term "block" is confusing here isn't it? "Block" is used
for both the extensibility mechanism for the BP and the name of
the payload bytes for LTP.

> 
> Scott

From: Lloyd Wood <[email-masked]>
Date: Wed, 6 Jan 2010 18:35:39 +0000
To: Stephen Farrell <[email-masked]>
Cc: dtn-interest <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Time was Re: QoS in DTN

On 6 Jan 2010, at 18:03, Stephen Farrell wrote:

>>> We also wrote up a draft [1] on alternative mechanisms and I'd
>>> love to see feedback on that rather than yet more carping on
>>> about "time as a problem". (The only reason I started that I-D
>>> was because no-one else had written one, despite the many
>>> mail messages on the topic.)
>> 
>> From that:
>> 
>>   The creation time field contains the wall-clock
>>   time at which the bundle was created. 
>> [..]
>>   Clocks may also vary randomly due to users changing timezones or
>>   (rarely) manipulating their clocks for other reasons (or having some
>>   semi-broken wannabe smart software running that does it for them).
>> 
>> Well, there's internal time, and there's displayed time using an offset - 
>> a different thing. The time is not the clock is not the clockface "wall
>> clock time", and many software implementations recognise that distinction.
>> (Unix/Mac: yes. Windows/DOS: not so much.)
> 
> Not quite sure what you're getting at there. (If its the same as the
> "say UTC" comment below then that's fine.)

changing the timezone doesn't change the clock - if the implementation
differentiates between 'displayed clock face' and 'actual time'. If
there's a 'timezone' setting, then the real-time clock is unaffected
by the display option, which is just an offset applied to the real time.
(basic GSM phones lack timezone consideration; smartphones have it.)

Of course, this presumes that the user knows to change the timezone
when moving across timezones, rather than changing the internal clock.

>> Some discussion of the leap seconds problem
>> would not go amiss.
> 
> Maybe. Perhaps just to say that they're not a real problem since
> the granularity of a bundle lifetime is one second anyway, but we
> could add a sentence I guess.

depends on length of deployment in the field without syncing, vs expiry
time. Eventually, nodes dormant in the field for a long time will
be out of sync with the ever-adjusted UTC. Might matter for a probe
investigating the Oort and dormant for years, but clock drift at low
temperatures is likely to be the dominant effect.

Really, everyone's implementing POSIX unix time, which isn't quite UTC,
and deriving UTC from that, which is backwards.

I'd have gone for TAI starting 1 Jan 1977: 00:00 myself.

>>> [1] http://tools.ietf.org/html/draft-farrell-dtnrg-alt-time

Interplanetary Internet tested in space http://tinyurl.com/ylxcj9s

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

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Wed, 6 Jan 2010 10:34:21 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] LTP CL

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Wednesday, January 06, 2010 10:26 AM
> To: Burleigh, Scott C (313B)
> Cc: dtn-interest
> Subject: Re: LTP CL
> 
> 
> 
> Burleigh, Scott C (313B) wrote:
> 
> > Okay, then, I think we've got no issue.  All I'm saying in
> > the LTPCL draft is that the content of each green-part
> > segment needs to be a complete bundle,
> 
> I think that's exactly where we do have an issue. I'm
> advocating that the LTP-CL not include that requirement
> since it limits the use of this LTP-CL spec for BP/LTP to
> cases with small bundles so that each LTP segment can be
> as big as a bundle. (Actually a little bigger of course.)

Stephen, why did you delete the context?

'> Except that you can't do *anything* with a fragment of a bundle.  You can do things with a bundle that is "a fragment", i.e., a complete bundle whose payload is a portion of the payload of some predecessor bundle.  But you can't do any more with an incomplete bundle than you can with an incomplete IP packet.

Fair enough on the terminology, what I meant was that the receiver could forward a reactively fragmented bundle based on the segments received. (Which was the entire point of reactive fragmentation wasn't it?)'

A truncated or shredded bundle is useless.  There is zero utility in drawing the red/green boundary in an LTP block in the middle of a bundle payload.  On the other hand, bundle fragmentation and reassembly solves the problem of sending arbitrarily large bundles via LTP, and it does so in a way that is already well documented in RFC 5050, so the constraint on bundle encapsulation in green segments doesn't preclude any functionality whatsoever.  I don't understand why you're arguing otherwise.

Scott

Date: Wed, 06 Jan 2010 18:26:25 +0000
From: Stephen Farrell <[email-masked]>
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] LTP CL

Burleigh, Scott C (313B) wrote:

> Okay, then, I think we've got no issue.  All I'm saying in 
> the LTPCL draft is that the content of each green-part
> segment needs to be a complete bundle,

I think that's exactly where we do have an issue. I'm
advocating that the LTP-CL not include that requirement
since it limits the use of this LTP-CL spec for BP/LTP to
cases with small bundles so that each LTP segment can be
as big as a bundle. (Actually a little bigger of course.)

As I said, I think the way to handle this is to require
that the red/green boundary be at a bundle boundary or
else within a bundle payload.

That does work, both for cases like yours with ~64KB
bundles and LTP segments, as well as for cases with large
bundles and (probably much) smaller LTP segments.

BTW, I'd have no problem at all to call an implementation
"conformant" if it only ever emits LTP segments that meet
your preferred rule. (Which is a "subset" of my preferred
rule.) I'd need to think about how receiver conformance
statements for such an implementation could be handled
though.

Stephen.

PS: Yet again I didn't see your mail coming from the
list so I'm not sure who's seeing what. The rest of
Scott's mail is below:

> ...which may itself be "a fragment" of some antecedent
> bundle created as a result of either reactive or proactive
> bundle fragmentation. You can send an arbitrarily large
> user data unit in a single original bundle via LTP, but
> when you want it to go out over Green LTP you use bundle
> fragmentation to generate a bunch of smaller "fragment"
> bundles whose payloads are subsets of the original
> bundle's payload; each of these "fragment" bundles is
> a complete bundle, which can go in a single green-part
> segment.
>
> What you're really doing here is letting LTP itself do
> fragmentation/reassembly of the Red part of the block but
> using BP fragmentation/reassembly for the Green part (since
> LTP doesn't do green-part reassembly on the client's behalf).
>
> Scott

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Wed, 6 Jan 2010 10:11:10 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] LTP CL

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Wednesday, January 06, 2010 9:47 AM
> To: Burleigh, Scott C (313B)
> Cc: dtn-interest
> Subject: Re: LTP CL
> 
> 
> Hi Scott,
> 
> Burleigh, Scott C (313B) wrote:
> >> -----Original Message-----
> >> From: Stephen Farrell [mailto:[email-masked]]
> >> Sent: Wednesday, January 06, 2010 8:19 AM
> >> To: Burleigh, Scott C (313B)
> >> Cc: DTN
> >> Subject: Re: LTP CL
> >>
> >>
> >> Scott,
> >>
> >> (cc'ing the dtn-interest list as agreed)
> >>
> >> Burleigh, Scott C (313B) wrote:
> >>>> -----Original Message-----
> >>>> From: Stephen Farrell [mailto:[email-masked]]
> >>>> Sent: Wednesday, December 30, 2009 9:10 AM
> >>>> To: Burleigh, Scott C (313B); DTN
> >>>> Subject: LTP CL
> >>>>
> >>>>
> >>>> Hi Scott,
> >>>>
> >>>> Just noticed you've published draft-burleigh-dtnrg-ltpcl-00, which
> >>>> is good.
> >>>>
> >>>> I'll probably have more comments later, but this part of the spec
> >>>> just seems wrong:
> >>>>
> >>>>    The requirement that green segment service data be self-identifying
> >>>>    to the client service -- in this case, the Bundle Protocol --
> implies
> >>>>    that the service data of each green segment must be a single
> complete
> >>>>    bundle, even if possibly a BP "fragment."
> >>>>
> >>>> Firstly, where's that "self-identifying" requirement come from? I
> >>>> don't recall it in the LTP RFCs. (But I didn't look, maybe its there.)
> >>> No, that "requirement" comes from earlier in the LTPCL draft.  It's
> >> explained in the third paragraph of section 2.
> >>
> >> I still don't see where the self-identifying requirement comes from.
> >
> > What I said was "The LTP specification implicitly mandates the reassembly
> of the red-part of a block into a contiguous byte array from received red
> segments, but it does not mandate the reassembly of the green-part from
> received green segments.  That is, any required reassembly of "green"
> service data is the responsibility of the client service.  For this reason,
> the service data in each green LTP data segment must be self-identifying so
> that the client service can either ingest the service data immediately or
> else use it in the reassembly of larger client service data objects that it
> can ingest."
> >
> > That is, what the client is going to get is each green segment
> individually, with enough information to reassemble the green-part if it
> all arrives.  But if it doesn't all arrive, it's got nothing unless there's
> enough information in the segments themselves to make those crumbs
> individually usable.
> 
> Ok. But I read self-identifying as requiring more, e.g. that
> the segment be a complete bundle, but if the receiver can
> usefully handle crumbs then that's ok then. I think that
> so long as the crumbs contain the initial bundle blocks and
> zero or more payload bytes that can be useful.
> 
> >> The receiver will know where any received green segments ought to go
> >> in the block. If green segments go missing, then reassembling the
> >> entire bundle is impossible, but you could e.g. forward on or
> >> deliver a fragment of that bundle.
> >
> > Except that you can't do *anything* with a fragment of a bundle.  You can
> do things with a bundle that is "a fragment", i.e., a complete bundle whose
> payload is a portion of the payload of some predecessor bundle.  But you
> can't do any more with an incomplete bundle than you can with an incomplete
> IP packet.
> 
> Fair enough on the terminology, what I meant was that the
> receiver could forward a reactively fragmented bundle based
> on the segments received. (Which was the entire point of
> reactive fragmentation wasn't it?)

Okay, then, I think we've got no issue.  All I'm saying in the LTPCL draft is that the content of each green-part segment needs to be a complete bundle, which may itself be "a fragment" of some antecedent bundle created as a result of either reactive or proactive bundle fragmentation.  You can send an arbitrarily large user data unit in a single original bundle via LTP, but when you want it to go out over Green LTP you use bundle fragmentation to generate a bunch of smaller "fragment" bundles whose payloads are subsets of the original bundle's payload; each of these "fragment" bundles is a complete bundle, which can go in a single green-part segment.

What you're really doing here is letting LTP itself do fragmentation/reassembly of the Red part of the block but using BP fragmentation/reassembly for the Green part (since LTP doesn't do green-part reassembly on the client's behalf).

Scott

Date: Wed, 06 Jan 2010 18:03:34 +0000
From: Stephen Farrell <[email-masked]>
To: Lloyd Wood <[email-masked]>
Cc: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] Time was Re: QoS in DTN

(This is the other mail that I didn't see back from the
list today.)

Hi Lloyd,

Thanks for those comments.

Lloyd Wood wrote:
> On 5 Jan 2010, at 10:23, Stephen Farrell wrote:
> 
>> Speaking as someone who doesn't think the current use of time
>> in RFC 5050 is the best approach...I disagree. There are cases
>> where time sync can be a pain, but I've not heard of it
>> stopping anyone using the BP. The above overstates the case.
> 
> If BP tests will fail because of, say, extreme clock drift in very
> low temperatures, the tester will make sure to sync clocks before
> doing the test, so that the test is successful. Because there
> can't be a problem with the test...

Fair enough. But nonetheless, the creationTime & expiry fields
have not prevented anyone from doing anything as far as I know.

>> We also wrote up a draft [1] on alternative mechanisms and I'd
>> love to see feedback on that rather than yet more carping on
>> about "time as a problem". (The only reason I started that I-D
>> was because no-one else had written one, despite the many
>> mail messages on the topic.)
> 
> From that:
> 
>    The creation time field contains the wall-clock
>    time at which the bundle was created. 
> [..]
>    Clocks may also vary randomly due to users changing timezones or
>    (rarely) manipulating their clocks for other reasons (or having some
>    semi-broken wannabe smart software running that does it for them).
> 
> Well, there's internal time, and there's displayed time using an offset - 
> a different thing. The time is not the clock is not the clockface "wall
> clock time", and many software implementations recognise that distinction.
> (Unix/Mac: yes. Windows/DOS: not so much.)

Not quite sure what you're getting at there. (If its the same as the
"say UTC" comment below then that's fine.)

> 
>    If you try to rely on operator-supplied time on your mobile and you
>    will sometimes find it jumping back and forth, e.g., by one hour as
>    happened to one of the authors recently.
> 
> (Doesn't that have security implications?) Generally that involves
> getting off a plane in a different timezone.

Yes, there are (at least) two possible security implications (if the
clock reset isn't secured). One is that you're vulnerable to someone
fibbing about the time which can have bad affects on applications, the
other is that you may get attacks related to key management (e.g. a
public key that is actually revoked might still appear valid).

Probably worth a note in the draft all right.

> Anyway, creation time in the Bundle Protocol is defined in seconds past
> 2000-00-00.00:00:00 UTC.
> 
> UTC is generally not wall-clock time anywhere in households (satellite
> control rooms and air traffic control are obvious exceptions), thanks
> to daylight savings... it's a misleading term.
> 
> Draft needs to remove all mention of 'wall-clock', and refer to the
> UTC time standard. 

Fair enough I guess. Will try to fix when we revise.

> Some discussion of the leap seconds problem
> would not go amiss.

Maybe. Perhaps just to say that they're not a real problem since
the granularity of a bundle lifetime is one second anyway, but we
could add a sentence I guess.

> 
>    Separately from the above, the requirement that bundles expire a
>    fixed number of seconds after their creation time has also
>    occasionally proven problematic.
> 
> It's not separate - if the creator's clock has drifted into the past,
> bundles get dropped at the next node, rather than delivered. Expiring
> after creation time is a feature; it's when creation time isn't
> universal it's a problem.

I do think there's a separate issue but maybe it needs to be
stated more clearly.

Issue #1 is requiring a good UTC value for the creationTime field.

Issue #2, which is separate, is requiring expiry to be expressed
in terms of seconds-after-creationTime, hence the hop-count
mechanism in the draft. We've had problems with issue#2 even with
good clock values when we did know exactly how many hops to
allow, but picked bad (too small) values for the expiry field.
(What happened was that a helicopter got diverted, so didn't
arrive to pick up bundles until after some had expired on a
mid-path node - I think they were re-transmitted so the
application just saw delay, but it'd have been better if they
hadn't expired at all.)

Cheers,
Stephen.

> 
>> [1] http://tools.ietf.org/html/draft-farrell-dtnrg-alt-time
> 
> Interplanetary Internet tested in space http://tinyurl.com/ylxcj9s
> 
> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> 
> 
> 
> 

Date: Wed, 06 Jan 2010 17:46:34 +0000
From: Stephen Farrell <[email-masked]>
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] LTP CL

Hi Scott,

Burleigh, Scott C (313B) wrote:
>> -----Original Message-----
>> From: Stephen Farrell [mailto:[email-masked]]
>> Sent: Wednesday, January 06, 2010 8:19 AM
>> To: Burleigh, Scott C (313B)
>> Cc: DTN
>> Subject: Re: LTP CL
>>
>>
>> Scott,
>>
>> (cc'ing the dtn-interest list as agreed)
>>
>> Burleigh, Scott C (313B) wrote:
>>>> -----Original Message-----
>>>> From: Stephen Farrell [mailto:[email-masked]]
>>>> Sent: Wednesday, December 30, 2009 9:10 AM
>>>> To: Burleigh, Scott C (313B); DTN
>>>> Subject: LTP CL
>>>>
>>>>
>>>> Hi Scott,
>>>>
>>>> Just noticed you've published draft-burleigh-dtnrg-ltpcl-00, which
>>>> is good.
>>>>
>>>> I'll probably have more comments later, but this part of the spec
>>>> just seems wrong:
>>>>
>>>>    The requirement that green segment service data be self-identifying
>>>>    to the client service -- in this case, the Bundle Protocol -- implies
>>>>    that the service data of each green segment must be a single complete
>>>>    bundle, even if possibly a BP "fragment."
>>>>
>>>> Firstly, where's that "self-identifying" requirement come from? I
>>>> don't recall it in the LTP RFCs. (But I didn't look, maybe its there.)
>>> No, that "requirement" comes from earlier in the LTPCL draft.  It's
>> explained in the third paragraph of section 2.
>>
>> I still don't see where the self-identifying requirement comes from.
> 
> What I said was "The LTP specification implicitly mandates the reassembly of the red-part of a block into a contiguous byte array from received red segments, but it does not mandate the reassembly of the green-part from received green segments.  That is, any required reassembly of "green" service data is the responsibility of the client service.  For this reason, the service data in each green LTP data segment must be self-identifying so that the client service can either ingest the service data immediately or else use it in the reassembly of larger client service data objects that it can ingest."
> 
> That is, what the client is going to get is each green segment individually, with enough information to reassemble the green-part if it all arrives.  But if it doesn't all arrive, it's got nothing unless there's enough information in the segments themselves to make those crumbs individually usable.

Ok. But I read self-identifying as requiring more, e.g. that
the segment be a complete bundle, but if the receiver can
usefully handle crumbs then that's ok then. I think that
so long as the crumbs contain the initial bundle blocks and
zero or more payload bytes that can be useful.

> 
>> The receiver will know where any received green segments ought to go
>> in the block. If green segments go missing, then reassembling the
>> entire bundle is impossible, but you could e.g. forward on or
>> deliver a fragment of that bundle.
> 
> Except that you can't do *anything* with a fragment of a bundle.  You can do things with a bundle that is "a fragment", i.e., a complete bundle whose payload is a portion of the payload of some predecessor bundle.  But you can't do any more with an incomplete bundle than you can with an incomplete IP packet.

Fair enough on the terminology, what I meant was that the
receiver could forward a reactively fragmented bundle based
on the segments received. (Which was the entire point of
reactive fragmentation wasn't it?)

> 
>>>> Secondly that requires the BP agent to know the segment sizing used
>>>> within the LTP CL (to use green segments). I don't think any other CL
>>>> has a similar requirement does it? Perhaps just limiting this to one
>>>> bundle per LTP session (or all-red or all-green) would be better and
>>>> a good bit simpler?
>>> One bundle per LTP session (block) would certainly be simpler, but that's
>> a non-starter for flight mission use of LTP; I've got to have that
>> aggregation function.
>>> Limiting a given session to all-red or all-green would be fine -- that's
>> actually how I've currently got it implemented -- but it doesn't make the
>> segment sizing question go away for green blocks.
>>> The sizing thing seems a little weird, but I think it's actually kind of
>> similar to what you're supposed to do in the Internet when you're using UDP
>> (which BP resembles in some ways): RFC 5405 talks about limiting UDP
>> datagrams per known network MTU size.  And it's a bit easier than the IP
>> equivalent because LTP is hop-by-hop: at each hop you can fragment the
>> bundle according to the segment size limit on that link, then reassemble
>> the bundle at the receiver and re-fragment according to the segment size on
>> the next link.
>>> Ugly, of course, but I don't see an obvious alternative.  Reassembling
>> the green-part of a block on the basis of offset and length is certainly
>> possible, except that if there's red and green data mixed in the block you
>> can't always know when you're done: the offset of the first segment in the
>> green-part will not be zero, so you can't know if you've gotten the first
>> segment in the green-part unless you get the EOR segment for the red part,
>> which might not happen.  And depending on that is likewise ugly.  I think
>> self-identifying green segment client data is the simplest way out.
>>
>> But there's a timer to protect against loss of the EOR so I
>> don't see the problem.
> 
> The problem is that the protection is not guaranteed.  The sender may never successfully send the EOR to you, despite the timer expiration.  Things happen.

If the BP is using LTP for reliable transmission, then the BP
depends on LTP working (which it does), so there's no real need
for the BPA & LTP-CA to bend over backwards just in case LTP's
reliable transmission fails - a BPA that did that is essentially
re-inventing part of LTP.

>> Limiting the LTPCLA to cases where green bundles fit in a
>> single LTP segment is IMO wrong, and unnecessary.
>>
>> It may work in your use-case where all bundles are small,
>> but it'd not work for large bundles, nor for cases where
>> LTP segments have to be small for whatever reason so I
>> really don't like it.
> 
> Okay, but I really do like it.

We really disagree then:-)

>> I think its sufficient to say that the red/green boundary MUST
>> be at a bundle boundary or within a bundle payload and
>> leave it at that. (I.e. that the red/green boundary MUST NOT
>> fall within any of the initial blocks of the bundle prior
>> to the payload.)
>>
>> If an application chooses to send green or partly green
>> bundles then its happy with unreliable transmission by
>> definition so if stuff gets lost, so be it.
>>
>> The reason I want to allow the red/green boundary to fall
>> within a payload is that allows for cases where a single
>> large bundle is sent as mixed red/green with all initial
>> bundle blocks and however much of the payload you want is
>> sent reliably. (That's gotta be more efficient for some
>> kinds of payload in terms of reduced overhead.)
>>
>> I'd imagine that the above constraint would also work
>> for your use-cases too.
> 
> But I don't think anybody is asking for that capability.  

I am.

> It's not needed for space flight operations,

Didn't the UK-DMC folks want exactly that? (A single large
bundle that is, they may not need LTP now.) I find it
hard to believe that no space scenario will ever call for
bundles that are bigger than ION's current 64K limit and
really don't think we should design the LTP-CL with that
as an assumption.

(I've certainly not seen any constraint to limit to small
bundles from ESA work, but to be honest neither have I seen
an explicit requirement for large bundles or small LTP
segments - however, I don't see any reason to preclude
such requirements.)

> and if you're using bundle authentication blocks it doesn't work at
all -- the block that contains the hash comes after the payload, so it
would be sent unreliably.

If any bytes go missing then the BAB will fail to verify
so where the red/green boundary is placed doesn't matter
if your policy requires BAB verification success later in
the path. (You could use LTP's segment authentication as
well/instead of course, and that's another comment I'll
make later on the LTP-CL draft - it should say what to
do about that if you do want it.)

Cheers,
S.

PS: I didn't see your message back from the dtn-interest
list even though it made it to the archive (2nd such
occurrence today - I'm checking out if its me or the
list), so we may need to replay some of this on the list
later.

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Prithwish Basu <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 6 Jan 2010 11:31:16 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] what about connectivity in DTN

Prithwish,

I like the term Eventually Transportable Dynamic Network (ETDN) as transport delay between nodes is generally much less a factor than disconnection time. Even the Contract Graph Routing algorithm for space-based networks has more to do with disconnection than delay (albeit, delay and bandwidth are used in the algorithm). "Eventually" infers nothing about how long eventually is.  

IMHO, Delay Tolerant Networking is a misleading term. In addition, to me, "Disruption" infers "short" time-periods of disconnection.  I would prefer the D in DTN to stand for Disconnection.  Alas, Once an acronym is set, there is no changing it.

Note, this is not an official NASA position, just my own.

--Will

======
From: [email-masked] [mailto:[email-masked]] On Behalf Of Prithwish Basu
Sent: Wednesday, January 06, 2010 7:24 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] what about connectivity in DTN

Here's another closely related paper in the same CHANTS 2007 conference which you may be interested in. This formalizes various types of DTNs with respect to various grades of "connectivity" from a routing perspective.

http://chants.cs.ucsb.edu/2007/papers/1-1.pdf

-Prithwish

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Wed, 6 Jan 2010 09:18:43 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] LTP CL

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Wednesday, January 06, 2010 8:19 AM
> To: Burleigh, Scott C (313B)
> Cc: DTN
> Subject: Re: LTP CL
> 
> 
> Scott,
> 
> (cc'ing the dtn-interest list as agreed)
> 
> Burleigh, Scott C (313B) wrote:
> >> -----Original Message-----
> >> From: Stephen Farrell [mailto:[email-masked]]
> >> Sent: Wednesday, December 30, 2009 9:10 AM
> >> To: Burleigh, Scott C (313B); DTN
> >> Subject: LTP CL
> >>
> >>
> >> Hi Scott,
> >>
> >> Just noticed you've published draft-burleigh-dtnrg-ltpcl-00, which
> >> is good.
> >>
> >> I'll probably have more comments later, but this part of the spec
> >> just seems wrong:
> >>
> >>    The requirement that green segment service data be self-identifying
> >>    to the client service -- in this case, the Bundle Protocol -- implies
> >>    that the service data of each green segment must be a single complete
> >>    bundle, even if possibly a BP "fragment."
> >>
> >> Firstly, where's that "self-identifying" requirement come from? I
> >> don't recall it in the LTP RFCs. (But I didn't look, maybe its there.)
> >
> > No, that "requirement" comes from earlier in the LTPCL draft.  It's
> explained in the third paragraph of section 2.
> 
> I still don't see where the self-identifying requirement comes from.

What I said was "The LTP specification implicitly mandates the reassembly of the red-part of a block into a contiguous byte array from received red segments, but it does not mandate the reassembly of the green-part from received green segments.  That is, any required reassembly of "green" service data is the responsibility of the client service.  For this reason, the service data in each green LTP data segment must be self-identifying so that the client service can either ingest the service data immediately or else use it in the reassembly of larger client service data objects that it can ingest."

That is, what the client is going to get is each green segment individually, with enough information to reassemble the green-part if it all arrives.  But if it doesn't all arrive, it's got nothing unless there's enough information in the segments themselves to make those crumbs individually usable.

> The receiver will know where any received green segments ought to go
> in the block. If green segments go missing, then reassembling the
> entire bundle is impossible, but you could e.g. forward on or
> deliver a fragment of that bundle.

Except that you can't do *anything* with a fragment of a bundle.  You can do things with a bundle that is "a fragment", i.e., a complete bundle whose payload is a portion of the payload of some predecessor bundle.  But you can't do any more with an incomplete bundle than you can with an incomplete IP packet.

> >> Secondly that requires the BP agent to know the segment sizing used
> >> within the LTP CL (to use green segments). I don't think any other CL
> >> has a similar requirement does it? Perhaps just limiting this to one
> >> bundle per LTP session (or all-red or all-green) would be better and
> >> a good bit simpler?
> >
> > One bundle per LTP session (block) would certainly be simpler, but that's
> a non-starter for flight mission use of LTP; I've got to have that
> aggregation function.
> >
> > Limiting a given session to all-red or all-green would be fine -- that's
> actually how I've currently got it implemented -- but it doesn't make the
> segment sizing question go away for green blocks.
> >
> > The sizing thing seems a little weird, but I think it's actually kind of
> similar to what you're supposed to do in the Internet when you're using UDP
> (which BP resembles in some ways): RFC 5405 talks about limiting UDP
> datagrams per known network MTU size.  And it's a bit easier than the IP
> equivalent because LTP is hop-by-hop: at each hop you can fragment the
> bundle according to the segment size limit on that link, then reassemble
> the bundle at the receiver and re-fragment according to the segment size on
> the next link.
> >
> > Ugly, of course, but I don't see an obvious alternative.  Reassembling
> the green-part of a block on the basis of offset and length is certainly
> possible, except that if there's red and green data mixed in the block you
> can't always know when you're done: the offset of the first segment in the
> green-part will not be zero, so you can't know if you've gotten the first
> segment in the green-part unless you get the EOR segment for the red part,
> which might not happen.  And depending on that is likewise ugly.  I think
> self-identifying green segment client data is the simplest way out.
> 
> But there's a timer to protect against loss of the EOR so I
> don't see the problem.

The problem is that the protection is not guaranteed.  The sender may never successfully send the EOR to you, despite the timer expiration.  Things happen.

> Limiting the LTPCLA to cases where green bundles fit in a
> single LTP segment is IMO wrong, and unnecessary.
> 
> It may work in your use-case where all bundles are small,
> but it'd not work for large bundles, nor for cases where
> LTP segments have to be small for whatever reason so I
> really don't like it.

Okay, but I really do like it.

> I think its sufficient to say that the red/green boundary MUST
> be at a bundle boundary or within a bundle payload and
> leave it at that. (I.e. that the red/green boundary MUST NOT
> fall within any of the initial blocks of the bundle prior
> to the payload.)
> 
> If an application chooses to send green or partly green
> bundles then its happy with unreliable transmission by
> definition so if stuff gets lost, so be it.
> 
> The reason I want to allow the red/green boundary to fall
> within a payload is that allows for cases where a single
> large bundle is sent as mixed red/green with all initial
> bundle blocks and however much of the payload you want is
> sent reliably. (That's gotta be more efficient for some
> kinds of payload in terms of reduced overhead.)
> 
> I'd imagine that the above constraint would also work
> for your use-cases too.

But I don't think anybody is asking for that capability.  It's not needed for space flight operations, and if you're using bundle authentication blocks it doesn't work at all -- the block that contains the hash comes after the payload, so it would be sent unreliably.

Scott

Date: Wed, 06 Jan 2010 16:18:38 +0000
From: Stephen Farrell <[email-masked]>
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] LTP CL

Scott,

(cc'ing the dtn-interest list as agreed)

Burleigh, Scott C (313B) wrote:
>> -----Original Message-----
>> From: Stephen Farrell [mailto:[email-masked]]
>> Sent: Wednesday, December 30, 2009 9:10 AM
>> To: Burleigh, Scott C (313B); DTN
>> Subject: LTP CL
>>
>>
>> Hi Scott,
>>
>> Just noticed you've published draft-burleigh-dtnrg-ltpcl-00, which
>> is good.
>>
>> I'll probably have more comments later, but this part of the spec
>> just seems wrong:
>>
>>    The requirement that green segment service data be self-identifying
>>    to the client service -- in this case, the Bundle Protocol -- implies
>>    that the service data of each green segment must be a single complete
>>    bundle, even if possibly a BP "fragment."
>>
>> Firstly, where's that "self-identifying" requirement come from? I
>> don't recall it in the LTP RFCs. (But I didn't look, maybe its there.)
> 
> No, that "requirement" comes from earlier in the LTPCL draft.  It's explained in the third paragraph of section 2.

I still don't see where the self-identifying requirement comes from.
The receiver will know where any received green segments ought to go
in the block. If green segments go missing, then reassembling the
entire bundle is impossible, but you could e.g. forward on or
deliver a fragment of that bundle.

>> Secondly that requires the BP agent to know the segment sizing used
>> within the LTP CL (to use green segments). I don't think any other CL
>> has a similar requirement does it? Perhaps just limiting this to one
>> bundle per LTP session (or all-red or all-green) would be better and
>> a good bit simpler?
> 
> One bundle per LTP session (block) would certainly be simpler, but that's a non-starter for flight mission use of LTP; I've got to have that aggregation function.
> 
> Limiting a given session to all-red or all-green would be fine -- that's actually how I've currently got it implemented -- but it doesn't make the segment sizing question go away for green blocks.
> 
> The sizing thing seems a little weird, but I think it's actually kind of similar to what you're supposed to do in the Internet when you're using UDP (which BP resembles in some ways): RFC 5405 talks about limiting UDP datagrams per known network MTU size.  And it's a bit easier than the IP equivalent because LTP is hop-by-hop: at each hop you can fragment the bundle according to the segment size limit on that link, then reassemble the bundle at the receiver and re-fragment according to the segment size on the next link.
> 
> Ugly, of course, but I don't see an obvious alternative.  Reassembling the green-part of a block on the basis of offset and length is certainly possible, except that if there's red and green data mixed in the block you can't always know when you're done: the offset of the first segment in the green-part will not be zero, so you can't know if you've gotten the first segment in the green-part unless you get the EOR segment for the red part, which might not happen.  And depending on that is likewise ugly.  I think self-identifying green segment client data is the simplest way out.

But there's a timer to protect against loss of the EOR so I
don't see the problem.

Limiting the LTPCLA to cases where green bundles fit in a
single LTP segment is IMO wrong, and unnecessary.

It may work in your use-case where all bundles are small,
but it'd not work for large bundles, nor for cases where
LTP segments have to be small for whatever reason so I
really don't like it.

I think its sufficient to say that the red/green boundary MUST
be at a bundle boundary or within a bundle payload and
leave it at that. (I.e. that the red/green boundary MUST NOT
fall within any of the initial blocks of the bundle prior
to the payload.)

If an application chooses to send green or partly green
bundles then its happy with unreliable transmission by
definition so if stuff gets lost, so be it.

The reason I want to allow the red/green boundary to fall
within a payload is that allows for cases where a single
large bundle is sent as mixed red/green with all initial
bundle blocks and however much of the payload you want is
sent reliably. (That's gotta be more efficient for some
kinds of payload in terms of reduced overhead.)

I'd imagine that the above constraint would also work
for your use-cases too.

Regards,
Stephen.

> 
> Scott

Date: Wed, 06 Jan 2010 15:37:30 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] IEEE Internet computing predictions for the next decade...

This month's IEEE Internet computing [1] has a bunch of essays
on predictions for the next decade, a bunch of which are free
to read. Dave Clark's [2] calls out DTN at an interestingly
high level. (Vint also has a good essay [3] on objects & storage.)

S.

[1] http://www.computer.org/portal/web/computingnow/archive/january2010
[2]
http://www.computer.org/portal/web/computingnow/0110/theme/internetcomputing3
[3]
http://www.computer.org/portal/web/computingnow/0110/theme/internetcomputing1

Date: Wed, 06 Jan 2010 12:23:31 +0000
From: Prithwish Basu <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] what about connectivity in DTN

This is a multi-part message in MIME format.
--------------070508050700070807040109
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit

Here's another closely related paper in the same CHANTS 2007 conference
which you may be interested in. This formalizes various types of DTNs
with respect to various grades of "connectivity" from a routing perspective.

http://chants.cs.ucsb.edu/2007/papers/1-1.pdf

-Prithwish

[email-masked] wrote:
> All - The following paper, which appeared in CHANTS 2007, formalizes
> notions of connectivity in wireless and mobile networks. The
> characterization is able to capture the spectrum from always-connected
> wired (or wireless) networks to never connected. We have follow-on
> work that examines time intervals.
>
> http://chants.cs.ucsb.edu/2007/papers/1-2.pdf
>
> Best -
>
> Ellen
>
> On Jan 5, 2010, at 7:13 AM, gogowang wrote:
>
>> hi
>> ------------------------------------------------------------------------
>> Wang Haiquan
>> tel:82317048
>> CollegeofSoftware,BeijingUniversityofAeronautics&Astronautics(BUAA)
>> BeijingUniversityofAeronautics&Astronautics(BUAA)
>> Building6#325
>> PostCode100191
>> ------------------------------------------------------------------------
>> *·¢¼þÈË£º*Avri Doria
>> *·¢ËÍÊ±¼ä£º*2010-01-0507:07:51
>> *ÊÕ¼þÈË£º*dtn-interest
>> *³ËÍ£º*
>> *Ö÷Ìâ£º*Re: [dtn-interest] what about connectivity in DTN
>> hi,
>> On4Jan2010,at11:50,Burleigh,ScottC(313B)wrote:
>> ....
>> >Maybewecansaysomethinglike¡°connectivityistheabilityoftopologicallyadjacentnetworknodestoexchangedata¡±.IntheInternet,connectivityisgenerallycontinuousanduninterrupted.InaDTN,connectivityisepisodic.What¡¯scommontothetwo,I¡¯llsuggest,istopologicaladjacency.IntheInternet,topologicaladjacencyiscoincidentwithandgenerallyindistinguishablefromconnectivity.InaDTN,Iwouldsaythattwonodescanbetopologicallyadjacent(neighborsinthenetwork)evenwhenthereiscurrentlynoconnectivitybetweenthem;thetopologicaladjacencyissomethingwecaninferfromourexpectationsoffutureconnectivity.
>> >
>> Wouldtherebevalueinanotionofconnectivityperunitinterval?
>> ...
>> >ForaDTNbasedonnon-scheduledcontactsthismaybetrickier.Ifwecanestimatetheprobabilityofafuturecontactthenmaybewecanstillusefullyimagineafour-dimensionalnetworktopologywherethefutureconnectivityedgesareweightedbyprobabilitysomehow,Idunno.Ithinkthegeneralconceptstillworks,though.NodeXistopologicallyadjacenttonodeYifthere¡¯sanon-zeroprobabilityoffuturebundleexchangebetweenXandY,it¡¯sjustthatthistopologicaladjacencystopsbeingaBooleanandbecomesBayesian.
>> ThisisprettymuchwhatwetrytodowiththeDeliveryPredictabilityparameterinPRoPHET(0<=P(A,B)<=1)
>> a.
>> ~~~~~~~but can this parameter be difine as afunction of time ? f(t)
>> _______________________________________________
>> dtn-interestmailinglist
>> [email-masked]
>> <mailto:[email-masked]>
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> <mailto:[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
>   

--------------070508050700070807040109
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=GB2312" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Here's another closely related paper in the same CHANTS 2007 conference
which you may be interested in. This formalizes various types of DTNs
with respect to various grades of "connectivity" from a routing
perspective.<br>
<br>
<a class="moz-txt-link-freetext" href="http://chants.cs.ucsb.edu/2007/papers/1-1.pdf">http://chants.cs.ucsb.edu/2007/papers/1-1.pdf</a><br>
<br>
-Prithwish<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> wrote:
<blockquote
 cite="mid:[email-masked]"
 type="cite"><base href="x-msg://2401/">All - The following paper,
which appeared in CHANTS 2007, formalizes notions of connectivity in
wireless and mobile networks. &nbsp;The characterization is able to capture
the spectrum from always-connected wired (or wireless) networks to
never connected. &nbsp;We have follow-on work that examines time intervals. &nbsp;
  <div><br>
  </div>
  <div><a moz-do-not-send="true"
 href="http://chants.cs.ucsb.edu/2007/papers/1-2.pdf">http://chants.cs.ucsb.edu/2007/papers/1-2.pdf</a></div>
  <div><br>
  </div>
  <div>Best -</div>
  <div><br>
  </div>
  <div>Ellen</div>
  <div><br>
  <div>
  <div>On Jan 5, 2010, at 7:13 AM, gogowang wrote:</div>
  <br class="Apple-interchange-newline">
  <blockquote type="cite">
    <div>
    <div>&nbsp;</div>
    <div><font face="Verdana" size="2">hi</font></div>
    <div>&nbsp;</div>
    <div align="left">
    <div align="left"><font face="Verdana" size="2">
    <hr style="width: 122px; height: 2px;" size="2"></font></div>
    <div><font face="Verdana" size="2">
    <div>
    <div>
    <div>&nbsp;
    <div>Wang Haiquan</div>
    <div>tel:82317048</div>
    <div>College&nbsp;of&nbsp;Software&nbsp;,&nbsp;Beijing&nbsp;University&nbsp;of&nbsp;Aeronautics&nbsp;&amp;&nbsp;Astronautics&nbsp;(BUAA)</div>
    <div>Beijing&nbsp;University&nbsp;of&nbsp;Aeronautics&nbsp;&amp;&nbsp;Astronautics&nbsp;(BUAA)</div>
    <div>Building&nbsp;6#&nbsp;325</div>
    <div>Post&nbsp;Code&nbsp;100191&nbsp;</div>
    </div>
    </div>
    </div>
    <div>&nbsp;</div>
    <hr></font></div>
    </div>
    <div><font face="Verdana"><font size="2"><strong>·¢¼þÈË£º</strong><span
 class="Apple-converted-space">&nbsp;</span>Avri Doria</font></font></div>
    <div><font face="Verdana"><font size="2"><strong>·¢ËÍÊ±¼ä£º</strong><span
 class="Apple-converted-space">&nbsp;</span>2010-01-05&nbsp;07:07:51</font></font></div>
    <div><font face="Verdana"><font size="2"><strong>ÊÕ¼þÈË£º</strong><span
 class="Apple-converted-space">&nbsp;</span>dtn-interest</font></font></div>
    <div><font face="Verdana"><font size="2"><strong>³ËÍ£º</strong></font></font></div>
    <div><font face="Verdana"><font size="2"><strong>Ö÷Ìâ£º</strong><span
 class="Apple-converted-space">&nbsp;</span>Re: [dtn-interest] what about
connectivity in DTN</font></font></div>
    <div>&nbsp;</div>
    <div><font face="Verdana" size="2">
    <div>hi,</div>
    <div>On&nbsp;4&nbsp;Jan&nbsp;2010,&nbsp;at&nbsp;11:50,&nbsp;Burleigh,&nbsp;Scott&nbsp;C&nbsp;(313B)&nbsp;wrote:</div>
    <div>....</div>
    <div>&gt;&nbsp;Maybe&nbsp;we&nbsp;can&nbsp;say&nbsp;something&nbsp;like&nbsp;¡°connectivity&nbsp;is&nbsp;the&nbsp;ability&nbsp;of&nbsp;topologically&nbsp;adjacent&nbsp;network&nbsp;nodes&nbsp;to&nbsp;exchange&nbsp;data¡±.&nbsp;&nbsp;In&nbsp;the&nbsp;Internet,&nbsp;connectivity&nbsp;is&nbsp;generally&nbsp;continuous&nbsp;and&nbsp;uninterrupted.&nbsp;&nbsp;In&nbsp;a&nbsp;DTN,&nbsp;connectivity&nbsp;is&nbsp;episodic.&nbsp;&nbsp;What¡¯s&nbsp;common&nbsp;to&nbsp;the&nbsp;two,&nbsp;I¡¯ll&nbsp;suggest,&nbsp;is&nbsp;topological&nbsp;adjacency.&nbsp;&nbsp;In&nbsp;the&nbsp;Internet,&nbsp;topological&nbsp;adjacency&nbsp;is&nbsp;coincident&nbsp;with&nbsp;and&nbsp;generally&nbsp;indistinguishable&nbsp;from&nbsp;connectivity.&nbsp;&nbsp;In&nbsp;a&nbsp;DTN,&nbsp;I&nbsp;would&nbsp;say&nbsp;that&nbsp;two&nbsp;nodes&nbsp;can&nbsp;be&nbsp;topologically&nbsp;adjacent&nbsp;(neighbors&nbsp;in&nbsp;the&nbsp;network)&nbsp;even&nbsp;when&nbsp;there&nbsp;is&nbsp;currently&nbsp;no&nbsp;connectivity
&nbsp;between&nbsp;them;&nbsp;the&nbsp;topological&nbsp;adjacency&nbsp;is&nbsp;something&nbsp;we&nbsp;can&nbsp;infer&nbsp;from&nbsp;our&nbsp;expectations&nbsp;of&nbsp;future&nbsp;connectivity.</div>
    <div>&gt;&nbsp;</div>
    <div>Would&nbsp;there&nbsp;be&nbsp;value&nbsp;in&nbsp;a&nbsp;notion&nbsp;of&nbsp;connectivity&nbsp;per&nbsp;unit&nbsp;interval?</div>
    <div>...</div>
    <div>&gt;&nbsp;For&nbsp;a&nbsp;DTN&nbsp;based&nbsp;on&nbsp;non-scheduled&nbsp;contacts&nbsp;this&nbsp;may&nbsp;be&nbsp;trickier.&nbsp;&nbsp;If&nbsp;we&nbsp;can&nbsp;estimate&nbsp;the&nbsp;probability&nbsp;of&nbsp;a&nbsp;future&nbsp;contact&nbsp;then&nbsp;maybe&nbsp;we&nbsp;can&nbsp;still&nbsp;usefully&nbsp;imagine&nbsp;a&nbsp;four-dimensional&nbsp;network&nbsp;topology&nbsp;where&nbsp;the&nbsp;future&nbsp;connectivity&nbsp;edges&nbsp;are&nbsp;weighted&nbsp;by&nbsp;probability&nbsp;somehow,&nbsp;I&nbsp;dunno.&nbsp;&nbsp;I&nbsp;think&nbsp;the&nbsp;general&nbsp;concept&nbsp;still&nbsp;works,&nbsp;though.&nbsp;&nbsp;Node&nbsp;X&nbsp;is&nbsp;topologically&nbsp;adjacent&nbsp;to&nbsp;node&nbsp;Y&nbsp;if&nbsp;there¡¯s&nbsp;a&nbsp;non-zero&nbsp;probability&nbsp;of&nbsp;future&nbsp;bundle&nbsp;exchange&nbsp;between&nbsp;X&nbsp;and&nbsp;Y,&nbsp;it¡¯s&nbsp;just&nbsp;that&nbsp;this&nbsp;topological&nbsp;adjacency&nbsp;stops&nbsp;being&nbsp;a&nbsp;Boolean&nbsp;and&nbsp;becomes&nbsp;Bay
esian.</div>
    <div>This&nbsp;is&nbsp;pretty&nbsp;much&nbsp;what&nbsp;we&nbsp;try&nbsp;to&nbsp;do&nbsp;with&nbsp;the&nbsp;Delivery&nbsp;&nbsp;Predictability&nbsp;parameter&nbsp;in&nbsp;PRoPHET&nbsp;&nbsp;(0&nbsp;&lt;=&nbsp;P(A,B)&nbsp;&lt;=&nbsp;1)</div>
    <div>a.</div>
    <div>~~~~~<font face="">~~but can this parameter be difine as a<span
 class="Apple-converted-space">&nbsp;</span><span class="Apple-style-span"
 style="word-spacing: 0px; font-family: arial,sans-serif; font-style: normal; font-variant: normal; font-weight: normal; font-size: small; line-height: normal; font-size-adjust: none; font-stretch: normal; text-transform: none; text-indent: 0px; white-space: normal; letter-spacing: normal; border-collapse: separate; orphans: 2; widows: 2;"><span
 class="Apple-style-span" style="line-height: 19px;">function of time
?&nbsp; f(t)</span></span></font></div>
    <div><span class="Apple-style-span"
 style="word-spacing: 0px; font-family: arial,sans-serif; font-style: normal; font-variant: normal; font-weight: normal; font-size: small; line-height: normal; font-size-adjust: none; font-stretch: normal; text-transform: none; text-indent: 0px; white-space: normal; letter-spacing: normal; border-collapse: separate; orphans: 2; widows: 2;"><span
 class="Apple-style-span" style="line-height: 19px;"></span></span>&nbsp;</div>
    <div>_______________________________________________</div>
    <div>dtn-interest&nbsp;mailing&nbsp;list</div>
    <div><a moz-do-not-send="true"
 href="mailto:[email-masked]"
 style="color: blue; text-decoration: underline;">[email-masked]</a></div>
    <div><a moz-do-not-send="true"
 href="http://maillists.intel-research.net/mailman/listinfo/dtn-interest"
 style="color: blue; text-decoration: underline;">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a></div>
    </font></div>
_______________________________________________<br>
dtn-interest mailing list<br>
    <a moz-do-not-send="true"
 href="mailto:[email-masked]"
 style="color: blue; text-decoration: underline;">[email-masked]</a><br>
    <a moz-do-not-send="true"
 href="http://maillists.intel-research.net/mailman/listinfo/dtn-interest"
 style="color: blue; text-decoration: underline;">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>
    </div>
  </blockquote>
  </div>
  <br>
  </div>
  <pre wrap="">
<hr size="4" width="90%">
_______________________________________________
dtn-interest mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="http://maillists.intel-research.net/mailman/listinfo/dtn-interest">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a>
  </pre>
</blockquote>
</body>
</html>

--------------070508050700070807040109--

From: Lloyd Wood <[email-masked]>
Date: Wed, 6 Jan 2010 10:43:04 +0000
To: Stephen Farrell <[email-masked]>
Cc: dtn-interest <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: [dtn-interest] Time was Re: QoS in DTN

On 5 Jan 2010, at 10:23, Stephen Farrell wrote:

> Speaking as someone who doesn't think the current use of time
> in RFC 5050 is the best approach...I disagree. There are cases
> where time sync can be a pain, but I've not heard of it
> stopping anyone using the BP. The above overstates the case.

If BP tests will fail because of, say, extreme clock drift in very
low temperatures, the tester will make sure to sync clocks before
doing the test, so that the test is successful. Because there
can't be a problem with the test...

> We also wrote up a draft [1] on alternative mechanisms and I'd
> love to see feedback on that rather than yet more carping on
> about "time as a problem". (The only reason I started that I-D
> was because no-one else had written one, despite the many
> mail messages on the topic.)

>From that:

   The creation time field contains the wall-clock
   time at which the bundle was created. 
[..]
   Clocks may also vary randomly due to users changing timezones or
   (rarely) manipulating their clocks for other reasons (or having some
   semi-broken wannabe smart software running that does it for them).

Well, there's internal time, and there's displayed time using an offset - 
a different thing. The time is not the clock is not the clockface "wall
clock time", and many software implementations recognise that distinction.
(Unix/Mac: yes. Windows/DOS: not so much.)

   If you try to rely on operator-supplied time on your mobile and you
   will sometimes find it jumping back and forth, e.g., by one hour as
   happened to one of the authors recently.

(Doesn't that have security implications?) Generally that involves
getting off a plane in a different timezone.

Anyway, creation time in the Bundle Protocol is defined in seconds past
2000-00-00.00:00:00 UTC.

UTC is generally not wall-clock time anywhere in households (satellite
control rooms and air traffic control are obvious exceptions), thanks
to daylight savings... it's a misleading term.

Draft needs to remove all mention of 'wall-clock', and refer to the
UTC time standard. Some discussion of the leap seconds problem
would not go amiss.

   Separately from the above, the requirement that bundles expire a
   fixed number of seconds after their creation time has also
   occasionally proven problematic.

It's not separate - if the creator's clock has drifted into the past,
bundles get dropped at the next node, rather than delivered. Expiring
after creation time is a feature; it's when creation time isn't
universal it's a problem.

> [1] http://tools.ietf.org/html/draft-farrell-dtnrg-alt-time

Interplanetary Internet tested in space http://tinyurl.com/ylxcj9s

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

Date: Tue, 05 Jan 2010 14:26:04 -0800
From: Katia <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] NetSciCom 2010: Deadline Extended!!

DEADLINE EXTENDED to JANUARY 12, 2010!!

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

                      NetSciCom 2010
       Second IEEE International Workshop on Network Science
                 For Communication Networks

            March 19, 2010 - San Diego, CA, USA
               http://netscicom2010.asu.edu/

          In conjunction with IEEE Infocom 2010
=====================================================================

SCOPE:

Network Science is a newly emerging discipline with applications in a
variety of domains, such as, Communication Networks, Power Grid
Networks, Transportation Networks, Social Networks, Biological Networks
and Economics. Designing complex communication networks of the future
needs a deep understanding of the interplay between the physical, the
communication, and the social networks involved. An understanding of
such interdependency can only be achieved by closer interaction between
Network Scientists, Communication Network Designers, and Social and
Behavioral Scientists. The goal of this workshop is to a provide a forum
where this diverse group of researchers can meet and exchange ideas that
will lead to deeper insights into the design of robust, efficient and
complex communication networks of the future.

TOPICS OF INTEREST:

The topics of this workshop lie at the intersection of Network Science
and Communication Network Design - including Topology Design and
Analysis, Traffic Modeling, Traffic Routing, Social Media Analysis:
blogs and friendship networks, Bio-inspired networks, Internet scale
measurement and analysis of online communities, Social network analysis
with mobile phone data, Interdependency between power grid,
communication and transportation networks.

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

PAPER SUBMISSION:

Papers should contain original material, i.e., that has not been
previously published or currently submitted elsewhere. Manuscripts
must be limited to 6 pages in IEEE 8.5x11 conference format, and
formatted in strict accordance with the IEEE Communications Society
author guidelines. All submissions will be handled
electronically. Accepted papers will be published on IEEExplore right
after
the conference. Camera ready versions are processed through the IEEE 
Conference eXpress website. Papers will be included in Infocom 2011 
proceedings.

For paper formatting instructions, please check

http://www.ieee-infocom.org/paper-layout.html

Prospective authors should submit their papers though EDAS. 
The submission link is 

http://edas.info/newPaper.php?c=8473

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

IMPORTANT DATES (all deadlines updated):

Workshop date: March 19, 2010

*** DEADLINE EXTENDED: JANUARY 12, 2010 ***

*** Notification of acceptance: February 15, 2010 ***

*** Camera-ready version submission deadline: March 5, 2010 ***

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

PROGRAM CO-CHAIRS/WORKSHOP ORGANIZERS:

Arun Sen, Arizona State U.
Andrea Richa, Arizona State U.
Katia Obraczka, UC Santa Cruz

PROGRAM COMMITTEE:

J. Altmann, Seoul National University, Korea
M. Boguna, University of Barcelona, Spain
R. Bonneau, AFOSR
W. Debany, AFRL
J. J. Garcia-Luna-Aceves, UCSC
A. Jukan, Braunschweig, Germany
G. Konjevod, ASU
H. T. Kung, Harvard Univ.
M. Latapy, CNRS, France
C. Magnien, CNRS, France
M. Medard, MIT
C. Qiao, University of Buffalo (SUNY)
K. Ramchandran, U.C. Berkeley
Y. Shavitt, Tel Aviv University, Israel
C. Scheideler, T.U. Munich
A. Spyropoulos, ETH Zurich, Switzerland
P. Varaiya, U.C. Berkeley
J. Walrand, U.C. Berkeley
G. Xue, ASU
J. Zhang, ASU

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

From: <[email-masked]>
To: <[email-masked]>
Date: Tue, 5 Jan 2010 08:08:46 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: [email-masked]
Subject: Re: [dtn-interest] what about connectivity in DTN

--_000_E518AB4B07DA42298FAE2B652A07D584ccgatechedu_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

--_000_E518AB4B07DA42298FAE2B652A07D584ccgatechedu_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<html><head><base href=3D"x-msg://2401/"></head><body style=3D"word-wrap: b=
reak-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;=
 ">All - The following paper, which appeared in CHANTS 2007, formalizes not=
ions of connectivity in wireless and mobile networks. &nbsp;The characteriz=
ation is able to capture the spectrum from always-connected wired (or wirel=
ess) networks to never connected. &nbsp;We have follow-on work that examine=
s time intervals. &nbsp;<div><br></div><div><a href=3D"http://chants.cs.ucs=
b.edu/2007/papers/1-2.pdf">http://chants.cs.ucsb.edu/2007/papers/1-2.pdf</a=
></div><div><br></div><div>Best -</div><div><br></div><div>Ellen</div><div>=
<br><div><div>On Jan 5, 2010, at 7:13 AM, gogowang wrote:</div><br class=3D=
"Apple-interchange-newline"><blockquote type=3D"cite"><div><div><font face=
=3D"Verdana" color=3D"#0000ff" size=3D"2"></font>&nbsp;</div><div><font fac=
e=3D"Verdana" size=3D"2">hi</font></div><div><font face=3D"Verdana" size=3D=
"2"></font>&nbsp;</div><div align=3D"left"><div align=3D"left"><font face=
=3D"Verdana" size=3D"2"><hr size=3D"2" style=3D"width: 122px; height: 2px; =
"></font></div><div><font color=3D"#c0c0c0"></font><div><font color=3D"#c0c=
0c0"><font face=3D"Verdana" size=3D"2"></font></font></div><font face=3D"Ve=
rdana" size=3D"2"><div><div><div><font face=3D"Verdana" size=3D"2"></font>&=
nbsp;<div>Wang Haiquan</div><div>tel:82317048</div><div>College&nbsp;of&nbs=
p;Software&nbsp;,&nbsp;Beijing&nbsp;University&nbsp;of&nbsp;Aeronautics&nbs=
p;&amp;&nbsp;Astronautics&nbsp;(BUAA)</div><div>Beijing&nbsp;University&nbs=
p;of&nbsp;Aeronautics&nbsp;&amp;&nbsp;Astronautics&nbsp;(BUAA)</div><div>Bu=
ilding&nbsp;6#&nbsp;325</div><div>Post&nbsp;Code&nbsp;100191&nbsp;</div></d=
iv></div></div><div>&nbsp;</div><hr></font></div></div><div><font face=3D"V=
erdana"><font size=3D"2"><strong>=B7=A2=BC=FE=C8=CB=A3=BA</strong><span cla=
ss=3D"Apple-converted-space">&nbsp;</span>Avri Doria</font></font></div><di=
v><font face=3D"Verdana"><font size=3D"2"><strong>=B7=A2=CB=CD=CA=B1=BC=E4=
=A3=BA</strong><span class=3D"Apple-converted-space">&nbsp;</span>2010-01-0=
5&nbsp;07:07:51</font></font></div><div><font face=3D"Verdana"><font size=
=3D"2"><strong>=CA=D5=BC=FE=C8=CB=A3=BA</strong><span class=3D"Apple-conver=
ted-space">&nbsp;</span>dtn-interest</font></font></div><div><font face=3D"=
Verdana"><font size=3D"2"><strong>=B3=AD=CB=CD=A3=BA</strong></font></font>=
</div><div><font face=3D"Verdana"><font size=3D"2"><strong>=D6=F7=CC=E2=A3=
=BA</strong><span class=3D"Apple-converted-space">&nbsp;</span>Re: [dtn-int=
erest] what about connectivity in DTN</font></font></div><div><font face=3D=
"Verdana" size=3D"2"></font>&nbsp;</div><div><font face=3D"Verdana" size=3D=
"2"><div>hi,</div><div></div><div>On&nbsp;4&nbsp;Jan&nbsp;2010,&nbsp;at&nbs=
p;11:50,&nbsp;Burleigh,&nbsp;Scott&nbsp;C&nbsp;(313B)&nbsp;wrote:</div><div=
></div><div>....</div><div></div><div>&gt;&nbsp;Maybe&nbsp;we&nbsp;can&nbsp=
;say&nbsp;something&nbsp;like&nbsp;=A1=B0connectivity&nbsp;is&nbsp;the&nbsp=
;ability&nbsp;of&nbsp;topologically&nbsp;adjacent&nbsp;network&nbsp;nodes&n=
bsp;to&nbsp;exchange&nbsp;data=A1=B1.&nbsp;&nbsp;In&nbsp;the&nbsp;Internet,=
&nbsp;connectivity&nbsp;is&nbsp;generally&nbsp;continuous&nbsp;and&nbsp;uni=
nterrupted.&nbsp;&nbsp;In&nbsp;a&nbsp;DTN,&nbsp;connectivity&nbsp;is&nbsp;e=
pisodic.&nbsp;&nbsp;What=A1=AFs&nbsp;common&nbsp;to&nbsp;the&nbsp;two,&nbsp=
;I=A1=AFll&nbsp;suggest,&nbsp;is&nbsp;topological&nbsp;adjacency.&nbsp;&nbs=
p;In&nbsp;the&nbsp;Internet,&nbsp;topological&nbsp;adjacency&nbsp;is&nbsp;c=
oincident&nbsp;with&nbsp;and&nbsp;generally&nbsp;indistinguishable&nbsp;fro=
m&nbsp;connectivity.&nbsp;&nbsp;In&nbsp;a&nbsp;DTN,&nbsp;I&nbsp;would&nbsp;=
say&nbsp;that&nbsp;two&nbsp;nodes&nbsp;can&nbsp;be&nbsp;topologically&nbsp;=
adjacent&nbsp;(neighbors&nbsp;in&nbsp;the&nbsp;network)&nbsp;even&nbsp;when=
&nbsp;there&nbsp;is&nbsp;currently&nbsp;no&nbsp;connectivity&nbsp;between&n=
bsp;them;&nbsp;the&nbsp;topological&nbsp;adjacency&nbsp;is&nbsp;something&n=
bsp;we&nbsp;can&nbsp;infer&nbsp;from&nbsp;our&nbsp;expectations&nbsp;of&nbs=
p;future&nbsp;connectivity.</div><div>&gt;&nbsp;</div><div></div><div>Would=
&nbsp;there&nbsp;be&nbsp;value&nbsp;in&nbsp;a&nbsp;notion&nbsp;of&nbsp;conn=
ectivity&nbsp;per&nbsp;unit&nbsp;interval?</div><div></div><div>...</div><d=
iv></div><div>&gt;&nbsp;For&nbsp;a&nbsp;DTN&nbsp;based&nbsp;on&nbsp;non-sch=
eduled&nbsp;contacts&nbsp;this&nbsp;may&nbsp;be&nbsp;trickier.&nbsp;&nbsp;I=
f&nbsp;we&nbsp;can&nbsp;estimate&nbsp;the&nbsp;probability&nbsp;of&nbsp;a&n=
bsp;future&nbsp;contact&nbsp;then&nbsp;maybe&nbsp;we&nbsp;can&nbsp;still&nb=
sp;usefully&nbsp;imagine&nbsp;a&nbsp;four-dimensional&nbsp;network&nbsp;top=
ology&nbsp;where&nbsp;the&nbsp;future&nbsp;connectivity&nbsp;edges&nbsp;are=
&nbsp;weighted&nbsp;by&nbsp;probability&nbsp;somehow,&nbsp;I&nbsp;dunno.&nb=
sp;&nbsp;I&nbsp;think&nbsp;the&nbsp;general&nbsp;concept&nbsp;still&nbsp;wo=
rks,&nbsp;though.&nbsp;&nbsp;Node&nbsp;X&nbsp;is&nbsp;topologically&nbsp;ad=
jacent&nbsp;to&nbsp;node&nbsp;Y&nbsp;if&nbsp;there=A1=AFs&nbsp;a&nbsp;non-z=
ero&nbsp;probability&nbsp;of&nbsp;future&nbsp;bundle&nbsp;exchange&nbsp;bet=
ween&nbsp;X&nbsp;and&nbsp;Y,&nbsp;it=A1=AFs&nbsp;just&nbsp;that&nbsp;this&n=
bsp;topological&nbsp;adjacency&nbsp;stops&nbsp;being&nbsp;a&nbsp;Boolean&nb=
sp;and&nbsp;becomes&nbsp;Bayesian.</div><div></div><div></div><div>This&nbs=
p;is&nbsp;pretty&nbsp;much&nbsp;what&nbsp;we&nbsp;try&nbsp;to&nbsp;do&nbsp;=
with&nbsp;the&nbsp;Delivery&nbsp;&nbsp;Predictability&nbsp;parameter&nbsp;i=
n&nbsp;PRoPHET&nbsp;&nbsp;(0&nbsp;&lt;=3D&nbsp;P(A,B)&nbsp;&lt;=3D&nbsp;1)<=
/div><div></div><div>a.</div><div>~~~~~<font face=3D"">~~but can this param=
eter be difine as a<span class=3D"Apple-converted-space">&nbsp;</span><span=
 class=3D"Apple-style-span" style=3D"word-spacing: 0px; font: normal normal=
 normal small/normal arial, sans-serif; text-transform: none; text-indent: =
0px; white-space: normal; letter-spacing: normal; border-collapse: separate=
; orphans: 2; widows: 2; "><span class=3D"Apple-style-span" style=3D"line-h=
eight: 19px; ">function of time ?&nbsp; f(t)</span></span></font></div><div=
><span class=3D"Apple-style-span" style=3D"word-spacing: 0px; font: normal =
normal normal small/normal arial, sans-serif; text-transform: none; text-in=
dent: 0px; white-space: normal; letter-spacing: normal; border-collapse: se=
parate; orphans: 2; widows: 2; "><span class=3D"Apple-style-span" style=3D"=
line-height: 19px; "></span></span>&nbsp;</div><div></div><div></div><div><=
/div><div>_______________________________________________</div><div>dtn-int=
erest&nbsp;mailing&nbsp;list</div><div><a href=3D"mailto:dtn-interest@maill=
ists.intel-research.net" style=3D"color: blue; text-decoration: underline; =
">[email-masked]</a></div><div><a href=3D"http:/=
/maillists.intel-research.net/mailman/listinfo/dtn-interest" style=3D"color=
: blue; text-decoration: underline; ">http://maillists.intel-research.net/m=
ailman/listinfo/dtn-interest</a></div></font></div>________________________=
_______________________<br>dtn-interest mailing list<br><a href=3D"mailto:d=
[email-masked]" style=3D"color: blue; text-decora=
tion: underline; ">[email-masked]</a><br><a href=
=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest" styl=
e=3D"color: blue; text-decoration: underline; ">http://maillists.intel-rese=
arch.net/mailman/listinfo/dtn-interest</a><br></div></blockquote></div><br>=
</div></body></html>=

--_000_E518AB4B07DA42298FAE2B652A07D584ccgatechedu_--

Date: Tue, 5 Jan 2010 20:13:44 +0800
From: "gogowang" <[email-masked]>
To: "Avri Doria" <[email-masked]>, "dtn-interest" <[email-masked]>
Subject: Re: [dtn-interest] what about connectivity in DTN

This is a multi-part message in MIME format.

--=====003_Dragon143857560762_=====
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

--=====003_Dragon143857560762_=====
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

--=====003_Dragon143857560762_=====--

Date: Tue, 5 Jan 2010 10:23:03 +0000
From: Stephen Farrell <[email-masked]>
To: Lloyd Wood <[email-masked]>
Cc: Ma Xuebin <[email-masked]>, dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] QoS in DTN

Just a couple of points.

Lloyd Wood wrote:
> On 5 Jan 2010, at 07:51, Elwyn Davies wrote:
> 
>> Actually DTN is more helpful in this than 
>> conventional IP networks because ther is no way to control this expiry 
>> time in IP (we try very hard to ignore time in IP networks!)
> 
> Well, IP's TTL was originally intended to be a second counter of unspecified accuracy (see p. 30 of RFC791) but didn't get implemented like that because real-world implementation and use quickly dictated otherwise - much as we're seeing implementations of the Bundle Protocol hitting problems with synchronising their clocks before being able to communicate successfully. In other words, consideration of clock time in IP networks was deliberately ignored in implementations, for good reason in the light of experience. Perhaps we will see the same for the Bundle Protocol?

Seems to me that that's off-topic for this thread, but however...

Speaking as someone who doesn't think the current use of time
in RFC 5050 is the best approach...I disagree. There are cases
where time sync can be a pain, but I've not heard of it
stopping anyone using the BP. The above overstates the case.

We also wrote up a draft [1] on alternative mechanisms and I'd
love to see feedback on that rather than yet more carping on
about "time as a problem". (The only reason I started that I-D
was because no-one else had written one, despite the many
mail messages on the topic.)

> 
> Really, comparing the Bundle Protocol (which lives over a number of convergence layers) with IP (which lives under a number of convergence layers for the Bundle Protocol) and discussing the BP's reliance on the clock as a feature is a bit like comparing IP with a MAC protocol, and criticising MAC protocol as unhelpful for not considering TTL - something unneeded for its operation.
> 
> A better comparison is between the Bundle Protocol and something also living over IP that moves data around - take HTTP, which has the Bundle Protocol's understanding of time, has time-related headers (Expiry: and Cache Control: headers), and can be used equivalently to the Bundle Protocol:
> 
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/dtn/http-dtn
> 
> 
>> As you may gather, I am what might be described as a 'QoS Sceptic'.  
>> Trying to persuade an end user that s/he has any sort of control over 
>> the delivery of an individual packet/bundle is at best a fantasy and at 
>> worst a cruel con trick.  This is primarily because in general the 
>> network does not have much/any control knobs that can be adjusted to 
>> affect this delivery. OTOH post-facto measurement of what happened and 
>> doing statistical analysis is clearly possible and desirable.
> 
> Hear, hear. The problem with QoS in general is that, first, one has to define exactly what one means by QoS and what is desired (lots of semantic games and talking past each other there), and second, to support it generally requires tight coupling, control loops, and engineering to do the optimisations that can enable the kind of QoS that is desired, while inadvertently causing QoS to fail horribly in other conditions that the engineering doesn't consider and support. In a non-optimised DTN network, implementing QoS becomes hard.

I fully agree with you and Elwyn on this one.

S.

[1] http://tools.ietf.org/html/draft-farrell-dtnrg-alt-time

> 
> L.
> 
> Interplanetary Internet tested in space http://tinyurl.com/ylxcj9s
> 
> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: Lloyd Wood <[email-masked]>
Date: Tue, 5 Jan 2010 09:56:55 +0000
To: Elwyn Davies <[email-masked]>
Cc: Ma Xuebin <[email-masked]>, dtn-interest <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] QoS in DTN

On 5 Jan 2010, at 07:51, Elwyn Davies wrote:

> Actually DTN is more helpful in this than 
> conventional IP networks because ther is no way to control this expiry 
> time in IP (we try very hard to ignore time in IP networks!)

Well, IP's TTL was originally intended to be a second counter of unspecified accuracy (see p. 30 of RFC791) but didn't get implemented like that because real-world implementation and use quickly dictated otherwise - much as we're seeing implementations of the Bundle Protocol hitting problems with synchronising their clocks before being able to communicate successfully. In other words, consideration of clock time in IP networks was deliberately ignored in implementations, for good reason in the light of experience. Perhaps we will see the same for the Bundle Protocol?

Really, comparing the Bundle Protocol (which lives over a number of convergence layers) with IP (which lives under a number of convergence layers for the Bundle Protocol) and discussing the BP's reliance on the clock as a feature is a bit like comparing IP with a MAC protocol, and criticising MAC protocol as unhelpful for not considering TTL - something unneeded for its operation.

A better comparison is between the Bundle Protocol and something also living over IP that moves data around - take HTTP, which has the Bundle Protocol's understanding of time, has time-related headers (Expiry: and Cache Control: headers), and can be used equivalently to the Bundle Protocol:

http://personal.ee.surrey.ac.uk/Personal/L.Wood/dtn/http-dtn

> As you may gather, I am what might be described as a 'QoS Sceptic'.  
> Trying to persuade an end user that s/he has any sort of control over 
> the delivery of an individual packet/bundle is at best a fantasy and at 
> worst a cruel con trick.  This is primarily because in general the 
> network does not have much/any control knobs that can be adjusted to 
> affect this delivery. OTOH post-facto measurement of what happened and 
> doing statistical analysis is clearly possible and desirable.

Hear, hear. The problem with QoS in general is that, first, one has to define exactly what one means by QoS and what is desired (lots of semantic games and talking past each other there), and second, to support it generally requires tight coupling, control loops, and engineering to do the optimisations that can enable the kind of QoS that is desired, while inadvertently causing QoS to fail horribly in other conditions that the engineering doesn't consider and support. In a non-optimised DTN network, implementing QoS becomes hard.

L.

Interplanetary Internet tested in space http://tinyurl.com/ylxcj9s

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

Date: Tue, 05 Jan 2010 07:51:15 +0000
From: Elwyn Davies <[email-masked]>
To: Ma Xuebin <[email-masked]>
Cc: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] QoS in DTN

Hi.

Measuring the delivery effectiveness of a DTN network is much discussed 
in the literature on routing in opportunistic networks.  This paper 
http://www.cs.umass.edu/~arun/papers/RAPID.pdf on the RAPID routing 
protocol is a good start.  Delivery effectiveness is probably the best 
measure of the 'QoS' of a DTN, but what exactly this means is a matter 
of ongoing discussion.

As with conventional IP networks, there is no way that the end user can 
seriously hope to specify the delay to be tolerated and have this 
honored by the network.  The best that can be done is for the end 
user/application to determine a time when the contents of a given 
message is no longer useful and set this as the expiry time of the 
bundle containing the data.  Actually DTN is more helpful in this than 
conventional IP networks because ther is no way to control this expiry 
time in IP (we try very hard to ignore time in IP networks!)

RFC 5050 in principle offers a small set of priorities that can be 
applied to bundles.  As with IP, trying to apply these to user bundles 
is probably impractical for many of the same reasons that are discussed 
in the IP literature (authorization, priority escalation, DoS, etc.)

As you may gather, I am what might be described as a 'QoS Sceptic'.  
Trying to persuade an end user that s/he has any sort of control over 
the delivery of an individual packet/bundle is at best a fantasy and at 
worst a cruel con trick.  This is primarily because in general the 
network does not have much/any control knobs that can be adjusted to 
affect this delivery. OTOH post-facto measurement of what happened and 
doing statistical analysis is clearly possible and desirable.

Regards,
Elwyn Davies

Ma Xuebin wrote:
> Hi all,
>  
> How to understand the QoS in DTN? We know the delay is an important 
> factor to be considered in QoS , but which is tolerated in DTN. Does 
> this mean that delay is not need considered in QoS of DTN? If so, then 
> we focus on what kind of factors?
>  
> 2010-01-05
> ------------------------------------------------------------------------
> Ma Xuebin
> ------------------------------------------------------------------------
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>   

Date: Tue, 5 Jan 2010 13:30:17 +0800
From: "shzhang" <[email-masked]>
To: "dtn-interest" <[email-masked]>
Organization: USTC
Subject: Re: [dtn-interest] QoS in DTN
Reply-To: [email-masked]

This is a multi-part message in MIME format.

--=====003_Dragon016708007838_=====
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

--=====003_Dragon016708007838_=====
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

--=====003_Dragon016708007838_=====--

Date: Tue, 5 Jan 2010 11:01:49 +0800
From: "Ma Xuebin" <[email-masked]>
To: "dtn-interest" <[email-masked]>
Organization: Inner Mongolia University
Subject: [dtn-interest] QoS in DTN

This is a multi-part message in MIME format.

--=====003_Dragon881635855817_=====
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi all,

How to understand the QoS in DTN? We know the delay is an important factor to be considered in QoS , but which is tolerated in DTN. Does this mean that delay is not need considered in QoS of DTN? If so, then we focus on what kind of factors?

2010-01-05 

Ma Xuebin 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.5897" name=GENERATOR><LINK 
href="BLOCKQUOTE{margin-Top: 0px; margin-Bottom: 0px; margin-Left: 2em}" 
rel=stylesheet></HEAD>
<BODY style="FONT-SIZE: 10pt; MARGIN: 10px; FONT-FAMILY: verdana">
<DIV><FONT face=Verdana size=2>Hi&nbsp;all,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>How to understand the QoS in DTN? We know the delay is&nbsp;an important 
factor&nbsp;to be considered in&nbsp;QoS&nbsp;, but which is tolerated in DTN. 
Does this mean that delay is not need considered in QoS of DTN? If so, then we 
focus on what kind of factors?</DIV>
<DIV><FONT face=Verdana size=2></FONT>&nbsp;</DIV>
<DIV align=left><FONT face=Verdana color=#c0c0c0 size=2>2010-01-05 
</FONT></DIV><FONT face=Verdana size=2>
<HR style="WIDTH: 122px; HEIGHT: 2px" align=left SIZE=2>

<DIV><FONT face=Verdana color=#c0c0c0 size=2><SPAN>Ma Xuebin</SPAN> 
</FONT></DIV></FONT></BODY></HTML>

--=====003_Dragon881635855817_=====--

From: Avri Doria <[email-masked]>
Date: Mon, 4 Jan 2010 18:05:59 -0500
To: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] what about connectivity in DTN

hi,

On 4 Jan 2010, at 11:50, Burleigh, Scott C (313B) wrote:

....

> Maybe we can say something like “connectivity is the ability of topologically adjacent network nodes to exchange data”.  In the Internet, connectivity is generally continuous and uninterrupted.  In a DTN, connectivity is episodic.  What’s common to the two, I’ll suggest, is topological adjacency.  In the Internet, topological adjacency is coincident with and generally indistinguishable from connectivity.  In a DTN, I would say that two nodes can be topologically adjacent (neighbors in the network) even when there is currently no connectivity between them; the topological adjacency is something we can infer from our expectations of future connectivity.
> 

Would there be value in a notion of connectivity per unit interval?

...

> For a DTN based on non-scheduled contacts this may be trickier.  If we can estimate the probability of a future contact then maybe we can still usefully imagine a four-dimensional network topology where the future connectivity edges are weighted by probability somehow, I dunno.  I think the general concept still works, though.  Node X is topologically adjacent to node Y if there’s a non-zero probability of future bundle exchange between X and Y, it’s just that this topological adjacency stops being a Boolean and becomes Bayesian.

This is pretty much what we try to do with the Delivery  Predictability parameter in PRoPHET  (0 <= P(A,B) <= 1)

a.

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: xlwujunying <[email-masked]>, dtn-interest <[email-masked]>
Date: Mon, 4 Jan 2010 08:50:23 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] what about connectivity in DTN

--_000_FD514C8A5155C64C9B145B48D674EF544A37F7AED0ALTPHYEMBEVSP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I think I see what you're getting at.  In the Internet we have a very clear=
 notion of "connectivity" because most of the devices that are participatin=
g in the network are connected nearly all the time, but in DTN this is not =
the case; we need a different term, or else a crisper definition of the ter=
m we already use.

Maybe we can say something like "connectivity is the ability of topological=
ly adjacent network nodes to exchange data".  In the Internet, connectivity=
 is generally continuous and uninterrupted.  In a DTN, connectivity is epis=
odic.  What's common to the two, I'll suggest, is topological adjacency.  I=
n the Internet, topological adjacency is coincident with and generally indi=
stinguishable from connectivity.  In a DTN, I would say that two nodes can =
be topologically adjacent (neighbors in the network) even when there is cur=
rently no connectivity between them; the topological adjacency is something=
 we can infer from our expectations of future connectivity.

This kind of thing is easiest to see when we're looking at DTN in space fli=
ght operations.  The "contact plan" we've been using as the basis for routi=
ng in NASA DTN experiments is a clear statement of scheduled future connect=
ivity, and it's been very natural to infer a sort of four-dimensional netwo=
rk topology from that statement.  At any single moment there may be some pa=
ir of nodes X and Y in the current network topology graph for which there i=
s no edge indicating connectivity.  But when you add a time dimension to th=
e graph you can show "storage" edges that extend through network time - rat=
her than through network space - and connect node X at time A (when there i=
s no XY edge) to node X at time B (when the XY edge comes into existence, a=
 scheduled contact), so that you can trace continuous data flow through the=
 network as easily as in the Internet: (X, A)-->(X,B)-->(Y,B).

For a DTN based on non-scheduled contacts this may be trickier.  If we can =
estimate the probability of a future contact then maybe we can still useful=
ly imagine a four-dimensional network topology where the future connectivit=
y edges are weighted by probability somehow, I dunno.  I think the general =
concept still works, though.  Node X is topologically adjacent to node Y if=
 there's a non-zero probability of future bundle exchange between X and Y, =
it's just that this topological adjacency stops being a Boolean and becomes=
 Bayesian.

Scott

From: [email-masked] [mailto:dtn-interes=
[email-masked]] On Behalf Of xlwujunying
Sent: Friday, January 01, 2010 12:07 AM
To: dtn-interest
Subject: Re: [dtn-interest] what about connectivity in DTN (Lloyd Wood)

Hi All,
Maybe I used the wrong word "measure".
I am not asking for any tools to compute the delay and some others.
What I wonder know is :  how can we identify the quality that we can send m=
essages in DTN but it is not really "connected".
In the tranditionnal network, we can send message between any pair of nodes=
 Only when the network is "connected".
but in DTN , we can send message when there is no "connectivity" at any mom=
ent in this network.this is a unique quality(property) of DTN.
how can we identify it, name it, formal it ?
what is its connotation?
and epitaxial?
--
KLBNT(Key Lab of Beijing of Network Technology)
BUAA(Beijing University of Aeronautics and Astronautics)

--_000_FD514C8A5155C64C9B145B48D674EF544A37F7AED0ALTPHYEMBEVSP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

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

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>I think I see what you&#8217;re getting at.=A0 In the Intern=
et we
have a very clear notion of &#8220;connectivity&#8221; because most of the
devices that are participating in the network are connected nearly all the
time, but in DTN this is not the case; we need a different term, or else a =
crisper
definition of the term we already use.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Maybe we can say something like &#8220;connectivity is</span=
> <span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'=
>the
ability of topologically adjacent network nodes to exchange data&#8221;.=A0=
 In
the Internet, connectivity is generally continuous and uninterrupted.=A0 In=
 a
DTN, connectivity is episodic.=A0 What&#8217;s common to the two, I&#8217;l=
l
suggest, is topological adjacency.=A0 In the Internet, topological adjacenc=
y is
coincident with and generally indistinguishable from connectivity.=A0 In a =
DTN, I
would say that two nodes can be topologically adjacent (neighbors in the
network) even when there is currently no connectivity between them; the
topological adjacency is something we can infer from our expectations of fu=
ture
connectivity.<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>This kind of thing is easiest to see when we&#8217;re lookin=
g at
DTN in space flight operations.=A0 The &#8220;contact plan&#8221; we&#8217;=
ve
been using as the basis for routing in NASA DTN experiments is a clear
statement of scheduled future connectivity, and it&#8217;s been very natura=
l to
infer a sort of four-dimensional network topology from that statement.=A0 A=
t any
single moment there may be some pair of nodes X and Y in the current networ=
k
topology graph for which there is no edge indicating connectivity.=A0 But w=
hen
you add a time dimension to the graph you can show &#8220;storage&#8221; ed=
ges
that extend through network time &#8211; rather than through network space =
&#8211;
and connect node X at time A (when there is no XY edge) to node X at time B=
 (when
the XY edge comes into existence, a scheduled contact), so that you can tra=
ce continuous
data flow through the network as easily as in the Internet: (X, A)</span><s=
pan
style=3D'font-size:11.0pt;font-family:Wingdings;color:#1F497D'>=E0</span><s=
pan
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'=
>(X,B)</span><span
style=3D'font-size:11.0pt;font-family:Wingdings;color:#1F497D'>=E0</span><s=
pan
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'=
>(Y,B).<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>For a DTN based on non-scheduled contacts this may be tricki=
er.=A0
If we can estimate the probability of a future contact then maybe we can st=
ill usefully
imagine a four-dimensional network topology where the future connectivity e=
dges
are weighted by probability somehow, I dunno.=A0 I think the general concep=
t still
works, though.=A0 Node X is topologically adjacent to node Y if there&#8217=
;s a
non-zero probability of future bundle exchange between X and Y, it&#8217;s =
just
that this topological adjacency stops being a Boolean and becomes Bayesian.=
<o:p></o:p></span></p>

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

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

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

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

<div>

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

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> dtn-interest-=
[email-masked]
[mailto:[email-masked]] <b>On Behalf Of =
</b>xlwujunying<br>
<b>Sent:</b> Friday, January 01, 2010 12:07 AM<br>
<b>To:</b> dtn-interest<br>
<b>Subject:</b> Re: [dtn-interest] what about connectivity in DTN (Lloyd Wo=
od)<o:p></o:p></span></p>

</div>

</div>

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

<div>

<p class=3DMsoNormal>Hi All,<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>Maybe I used the wrong word &quot;measure&quot;. <o:p>=
</o:p></p>

</div>

<div>

<p class=3DMsoNormal>I am not asking for any tools to compute the delay and=
 some
others.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>What I wonder know is :<span style=3D'font-family:"Cal=
ibri","sans-serif"'>&nbsp;</span>
how can we identify the quality that we can send messages in DTN but it is =
not
really &quot;connected&quot;.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>In the tranditionnal network, we can send message betw=
een
any pair of nodes Only when the network is &quot;connected&quot;.<o:p></o:p=
></p>

</div>

<div>

<p class=3DMsoNormal>but in DTN , we can send message when there is no
&quot;connectivity&quot; at any<span style=3D'font-family:"Calibri","sans-s=
erif"'>&nbsp;</span>moment
in this network.this is a unique quality(property) of DTN. <o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>how can we identify it, name it, formal it ?<o:p></o:p=
></p>

</div>

<div>

<p class=3DMsoNormal>what is its connotation?<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>and epitaxial?<span style=3D'font-size:14.5pt;font-fam=
ily:
"Arial","sans-serif";color:black'><br>
</span>--<o:p></o:p></p>

</div>

<div>

<div>

<p class=3DMsoNormal>KLBNT(Key Lab of Beijing of Network Technology)<o:p></=
o:p></p>

</div>

<div>

<p class=3DMsoNormal>BUAA(<span class=3Dapple-style-span><span style=3D'fon=
t-family:
"Arial","sans-serif";color:black'>Beijing University of Aeronautics and
Astronautics</span></span>)<o:p></o:p></p>

</div>

</div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><o:p>&nbsp;</o:p></p>

</div>

</div>

</body>

</html>

--_000_FD514C8A5155C64C9B145B48D674EF544A37F7AED0ALTPHYEMBEVSP_--

Date: Fri, 1 Jan 2010 20:51:03 -0800 (PST)
From: Fathima Rahaman <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] "Re: Contents of dtn-interest digest..."

--0-758326553-1262407863=:53903
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,
DTN operates with the principle of Store carry and forward.
When there is no path to reach destination is available, it operates with a=
bove principle.
by storing i don't=A0understand =A0how the quality differs?

--- On Sat, 1/2/10, [email-masked] <dtn-=
[email-masked]> wrote:

From: [email-masked] <dtn-interest-reque=
[email-masked]>
Subject: dtn-interest Digest, Vol 28, Issue 1
To: [email-masked]
Date: Saturday, January 2, 2010, 1:30 AM

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

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

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

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

Today's Topics:

=A0=A0=A01. Re: what about connectivity in DTN (Lloyd Wood) (xlwujunying)

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

Message: 1
Date: Fri, 1 Jan 2010 16:06:43 +0800 (CST)
From: xlwujunying <[email-masked]>
Subject: Re: [dtn-interest] what about connectivity in DTN (Lloyd
=A0=A0=A0 Wood)
To: dtn-interest <[email-masked]>
Message-ID:
=A0=A0=A0 <[email-masked]>
Content-Type: text/plain; charset=3D"gbk"

Hi All,
Maybe I used the wrong word "measure".=20
I am not asking for any tools to compute the delay and some others.
What I wonder know is :=A0 how can we identify the quality that we can send=
 messages in DTN but it is not really "connected".
In the tranditionnal network, we can send message between any pair of nodes=
 Only when the network is "connected".
but in DTN , we can send message when there is no "connectivity" at any mom=
ent in this network.this is a unique quality(property) of DTN.=20
how can we identify it, name it, formal it ?
what is its connotation?
and epitaxial?
--

KLBNT(Key Lab of Beijing of Network Technology)
BUAA(Beijing University of Aeronautics and Astronautics)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://maillists.intel-research.net/pipermail/dtn-interest/attachments=
/20100101/e23c3c6e/attachment-0001.html=20

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

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

End of dtn-interest Digest, Vol 28, Issue 1
*******************************************
=0A=0A=0A      
--0-758326553-1262407863=:53903
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><DIV>Hi,</DIV>
<DIV>DTN operates with the principle of Store carry and forward.</DIV>
<DIV>When there is no path to reach destination is available, it operates w=
ith above principle.</DIV>
<DIV>by storing i don't&nbsp;understand &nbsp;how the quality differs?</DIV=
>
<DIV><BR><BR>--- On <B>Sat, 1/2/10, [email-masked]=
search.net <I>&lt;[email-masked]&gt;</I>=
</B> wrote:<BR></DIV>
<BLOCKQUOTE style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(=
16,16,255) 2px solid"><BR>From: [email-masked]=
ch.net &lt;[email-masked]&gt;<BR>Subject=
: dtn-interest Digest, Vol 28, Issue 1<BR>To: [email-masked]=
research.net<BR>Date: Saturday, January 2, 2010, 1:30 AM<BR><BR>
<DIV class=3DplainMail>Send dtn-interest mailing list submissions to<BR>&nb=
sp;&nbsp;&nbsp; <A href=3D"http://us.mc361.mail.yahoo.com/mc/compose?to=3Dd=
[email-masked]" ymailto=3D"mailto:dtn-interest@ma=
illists.intel-research.net">[email-masked]</A><B=
R><BR>To subscribe or unsubscribe via the World Wide Web, visit<BR>&nbsp;&n=
bsp;&nbsp; <A href=3D"http://maillists.intel-research.net/mailman/listinfo/=
dtn-interest" target=3D_blank>http://maillists.intel-research.net/mailman/l=
istinfo/dtn-interest</A><BR>or, via email, send a message with subject or b=
ody 'help' to<BR>&nbsp;&nbsp;&nbsp; <A href=3D"http://us.mc361.mail.yahoo.c=
om/mc/compose?to=[email-masked]" ymail=
to=3D"mailto:[email-masked]">dtn-interes=
[email-masked]</A><BR><BR>You can reach the person =
managing the list at<BR>&nbsp;&nbsp;&nbsp; <A
 href=3D"http://us.mc361.mail.yahoo.com/mc/compose?to=3Ddtn-interest-owner@=
maillists.intel-research.net" ymailto=3D"mailto:dtn-interest-owner@maillist=
s.intel-research.net">[email-masked]</A><B=
R><BR>When replying, please edit your Subject line so it is more specific<B=
R>than "Re: Contents of dtn-interest digest..."<BR><BR><BR>Today's Topics:<=
BR><BR>&nbsp;&nbsp;&nbsp;1. Re: what about connectivity in DTN (Lloyd Wood)=
 (xlwujunying)<BR><BR><BR>-------------------------------------------------=
---------------------<BR><BR>Message: 1<BR>Date: Fri, 1 Jan 2010 16:06:43 +=
0800 (CST)<BR>From: xlwujunying &lt;<A href=3D"http://us.mc361.mail.yahoo.c=
om/mc/compose?to=[email-masked]" ymailto=3D"mailto:[email-masked]=
om">[email-masked]</A>&gt;<BR>Subject: Re: [dtn-interest] what about c=
onnectivity in DTN (Lloyd<BR>&nbsp;&nbsp;&nbsp; Wood)<BR>To: dtn-interest &=
lt;<A
 href=3D"http://us.mc361.mail.yahoo.com/mc/compose?to=3Ddtn-interest@mailli=
sts.intel-research.net" ymailto=3D"mailto:[email-masked]=
arch.net">[email-masked]</A>&gt;<BR>Message-ID:<=
BR>&nbsp;&nbsp;&nbsp; &lt;<A href=3D"http://us.mc361.mail.yahoo.com/mc/comp=
ose?to=[email-masked]" ym=
ailto=3D"mailto:[email-masked].=
com">[email-masked]</A>&gt;=
<BR>Content-Type: text/plain; charset=3D"gbk"<BR><BR>Hi All,<BR>Maybe I use=
d the wrong word "measure". <BR>I am not asking for any tools to compute th=
e delay and some others.<BR>What I wonder know is :&nbsp; how can we identi=
fy the quality that we can send messages in DTN but it is not really "conne=
cted".<BR>In the tranditionnal network, we can send message between any pai=
r of nodes Only when the network is "connected".<BR>but in DTN , we can sen=
d
 message when there is no "connectivity" at any moment in this network.this=
 is a unique quality(property) of DTN. <BR>how can we identify it, name it,=
 formal it ?<BR>what is its connotation?<BR>and epitaxial?<BR>--<BR><BR>KLB=
NT(Key Lab of Beijing of Network Technology)<BR>BUAA(Beijing University of =
Aeronautics and Astronautics)<BR>-------------- next part --------------<BR=
>An HTML attachment was scrubbed...<BR>URL: <A href=3D"http://maillists.int=
el-research.net/pipermail/dtn-interest/attachments/20100101/e23c3c6e/attach=
ment-0001.html" target=3D_blank>http://maillists.intel-research.net/piperma=
il/dtn-interest/attachments/20100101/e23c3c6e/attachment-0001.html</A> <BR>=
<BR>------------------------------<BR><BR>_________________________________=
______________<BR>dtn-interest mailing list<BR><A href=3D"http://us.mc361.m=
ail.yahoo.com/mc/compose?to=[email-masked]"
 ymailto=3D"mailto:[email-masked]">dtn-interest@=
maillists.intel-research.net</A><BR><A href=3D"http://maillists.intel-resea=
rch.net/mailman/listinfo/dtn-interest" target=3D_blank>http://maillists.int=
el-research.net/mailman/listinfo/dtn-interest</A><BR><BR><BR>End of dtn-int=
erest Digest, Vol 28, Issue 1<BR>******************************************=
*<BR></DIV></BLOCKQUOTE></td></tr></table><br>=0A=0A      
--0-758326553-1262407863=:53903--

Date: Fri, 1 Jan 2010 16:06:43 +0800 (CST)
From: xlwujunying <[email-masked]>
To: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] what about connectivity in DTN (Lloyd Wood)

------=_Part_19601_13550055.1262333203170
Content-Type: text/plain; charset=gbk
Content-Transfer-Encoding: 7bit

Hi All,
Maybe I used the wrong word "measure". 
I am not asking for any tools to compute the delay and some others.
What I wonder know is :  how can we identify the quality that we can send messages in DTN but it is not really "connected".
In the tranditionnal network, we can send message between any pair of nodes Only when the network is "connected".
but in DTN , we can send message when there is no "connectivity" at any moment in this network.this is a unique quality(property) of DTN. 
how can we identify it, name it, formal it ?
what is its connotation?
and epitaxial?
--

KLBNT(Key Lab of Beijing of Network Technology)
BUAA(Beijing University of Aeronautics and Astronautics)
------=_Part_19601_13550055.1262333203170
Content-Type: text/html; charset=gbk
Content-Transfer-Encoding: 7bit

<DIV>Hi All,</DIV>
<DIV>Maybe I used the wrong word "measure". </DIV>
<DIV>I am not asking for any tools to compute the delay and some others.</DIV>
<DIV>What I wonder know is :&nbsp; how can we identify the quality that we can send messages in DTN but it is not really "connected".</DIV>
<DIV>In the tranditionnal network, we can send message between any pair of nodes Only when the network is "connected".</DIV>
<DIV>but in DTN , we can send message when there is no "connectivity" at any&nbsp;moment in this network.this is a unique quality(property) of DTN. </DIV>
<DIV>how can we identify it, name it, formal it ?</DIV>
<DIV>what is its connotation?</DIV>
<DIV>and epitaxial?<SPAN class="Apple-style-span" style="WORD-SPACING: 0px; FONT: medium Simsun; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; orphans: 2; widows: 2; webkit-border-horizontal-spacing: 0px; webkit-border-vertical-spacing: 0px; webkit-text-decorations-in-effect: none; webkit-text-size-adjust: auto; webkit-text-stroke-width: 0px"><SPAN class="Apple-style-span" style="FONT-SIZE: 19px; LINE-HEIGHT: 25px; FONT-FAMILY: Arial, sans-serif"><BR class="Apple-interchange-newline"></SPAN></SPAN>--<BR></DIV>
<DIV>
<DIV>KLBNT(Key Lab of Beijing of Network Technology)</DIV>
<DIV>BUAA(<SPAN class="Apple-style-span" style="WORD-SPACING: 0px; FONT: small arial, sans-serif; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; orphans: 2; widows: 2; webkit-border-horizontal-spacing: 0px; webkit-border-vertical-spacing: 0px; webkit-text-decorations-in-effect: none; webkit-text-size-adjust: auto; webkit-text-stroke-width: 0px"><SPAN class="Apple-style-span" style="LINE-HEIGHT: 20px">Beijing University of Aeronautics and Astronautics</SPAN></SPAN>)</DIV></DIV><br><br><span title="neteasefooter"/></span>
------=_Part_19601_13550055.1262333203170--