Subject: [dtn-interest] CFP: IEEE Sensor and Ad Hoc Communications and Networks
From: "Adrian J. Hooke" <[email-masked]>
To: [email-masked]
Date: Thu, 29 Apr 2004 07:47:14 -0700
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

A DTN paper (or two) would seem to be in order?

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

			   IEEE SECON 2004

	First Annual IEEE Communications Society Conference on
	    Sensor and Ad Hoc Communications and Networks

		     Technically Co-Sponsored By:
			   IEEE ComSoc TCCC

		       Santa Clara, California
			  October 4-7, 2004

	    Paper submissions due (via EDAS): June 7, 2004

		    http://www.ieee-secon.org/2004
==========================================================================

The convergence of the Internet, communications and information
technologies, coupled with recent engineering advances, is paving the
way for a new generation of inexpensive mobile devices, sensors and
actuators.  It is the distributed and ad hoc deployment of networks of
these network devices and sensors that bears promises for a
significant impact, not only on science and engineering, but equally
importantly on a broad range of applications relating to critical
infrastructure protection and security, health care, the environment,
energy, food safety, production processing, quality of life, and the
economy.

This new IEEE Communications Society conference will provide a forum
to exchange ideas, techniques, and applications, discuss best
practices, raise awareness and share experiences among researchers,
practitioners, standard developers and policy makers in the field of
sensor and ad hoc networks and systems. The conference will be
organized to provide for a degree of collegiality and continuity in
the discussions of the various topics among participants from the
industrial, governmental and academic sectors.

Original technical papers, which address the communications,
networking, systems and algorithmic aspects of ad hoc and sensor
networks, as well as those that describe practical deployment and
implementation experiences are solicited for presentation at the
conference and publication in the conference proceedings.  Papers
presenting novel contributions in such disciplines as digital signal
processing, communications, networking protocols and architectures,
algorithms, embedded systems, middleware and information management,
and novel applications are solicited.

PAPERS:

Two types of submissions will be accepted for review in this
conference:

* FULL papers describing original, previously unpublished research
   work, experimental efforts, practical experiences, and industrial
   and commercial developments in sensor and ad hoc communications and
   networks.  Papers with a deep focus on a specific discipline or
   stimulated by the synergistic interaction of diverse disciplines are
   encouraged.

* SHORT papers focusing on future research directions, industry
   challenges and novel approaches in the field of sensor and ad hoc
   communications and networks. Papers in this category must be
   visionary, innovative and forward- looking.

Particular topics of interest include, but are not limited to:

* New architectures, protocols and access control to support
   communication, localization, time synchronization, routing and data
   dissemination in heterogeneous, large-scale distributed, ad hoc
   networks and sensor networks

* Novel algorithms and theories for management, supervisory control
   and monitoring of distributed ad hoc networks, and techniques for
   the interpretation and use of sensor data in decision-making
   processes

* Industrial and commercial developments and applications

* Modeling and performance evaluation of large-scale distributed and
   ad hoc sensor networks, practical implementations, and real-work
   experiences

* Theories and models on fundamental information and communication
   aspects of wireless ad hoc and sensor networks

* Mechanisms for authenticated, secure communication and data
   dissemination in sensor and ad hoc networks

* Integration of sensors into engineered systems, including novel
   techniques for sensor renewable power sources, mechanisms for
   on-sensor self- calibration and self-testing and efficient schemes
   to maximize accuracy and minimize false alarms

* Chip-based systems incorporating multiple sensors, computation,
   actuation, and wireless interfaces

* Software platforms, middleware and tools for ad hoc and sensor
   network applications development, deployment and management

TUTORIALS AND PANELS:

   Proposals for tutorials and panels on current topics in the field of
   ad hoc and sensor networking and applications are solicited. Panels
   related to the commercial application and development of sensors and
   ad hoc networks are especially encouraged.

DEMOS AND EXPO:

   Demonstrations that showcase the practical implementations,
   industrial and commercial developments, and new applications for ad
   hoc and sensor networks are solicited.

SUBMISSION AND REVIEW PROCESS:

* All submissions will be handled electronically via EDAS
   (http://edas.info).

   Please refer to the appropriate link and information at the
   conference website, http://www.ieee-secon.org/2004.

* The conference will only accept for review original papers that have
   not been previously published and are not currently under review by
   another conference or journal. All submissions will be handled
   electronically and must be in PDF or PostScript format.

* The length of FULL papers (describing original, previously
   unpublished research work, experimental efforts, practical
   experiences, etc.) must NOT exceed 10 IEEE conference-style pages
   (US "Letter" size, 8.5 x 11 inches) including text, figures and
   references, in two-column, single-space format, with a font size of
   11 points.

* The length of SHORT papers (focusing on future research directions,
   industry challenges, highly novel approaches, etc.) must not exceed
   6 IEEE conference-style pages (US "Letter" size, 8.5 x 11 inches)
   including text, figures and references, in two-column, single-space
   format, with a font size of 11 points.

* Papers not following these guidelines will be rejected.

* All submissions will be reviewed for technical merits and relevance
   to the conference.

* Accepted papers will be published in the conference proceedings.

IMPORTANT DATES:

Paper submissions due:		June 7, 2004
Tutorial/Panel Proposals due:	July 12, 2004
Notification date:		August 1, 2004
Camera-ready version due:	August 20, 2004

GENERAL CHAIR:

Taieb Znati, University of Pittsburgh, and NSF
[email-masked]

GENERAL VICE-CHAIR:

C. S. Raghavendra, University of Southern California
[email-masked]

TECHNICAL PROGRAM CO-CHAIRS:

Sung-Ju Lee            Prasant Mohapatra            Krishna Sivalingam
HP Laboratories        UC Davis                     UMBC
[email-masked]       [email-masked]	    [email-masked]

For more information, please visit the conference website
http://www.ieee-secon.org/2004 or contact one of the conference
co-chairs.

TECHNICAL PROGRAM COMMITTEE

Prathima Agrawal, Auburn
Kevin Almeroth, UCSB
Mary Baker, HP Labs
Suman Banerjee, University of Wisconsin
Stefano Basagni, Northeastern
Elizabeth Belding-Royer, UCSB
Christian Bettstetter, DoCoMo Euro-Labs
Philippe Bonnet, University of Copenhagen
Andrew Campbell, Columbia
Erdal Cayirci, Istanbul Technical University
Surendar Chandra, Notre Dame
Marco Conti, IIT Institute - CNR Pisa
David Culler, UC Berkeley
Samir Das, SUNY Stony Brook
Anthony Ephremides, University of Maryland
Deborah Estrin, UCLA
John Fisher, MIT
JJ Garcia-Luna-Aceves, UCSC
Mario Gerla, UCLA
Silvia Giordano, SUPSI of Lugano
Zygmunt Haas, Cornell University
Richard Han, University of Colorado
Paul Havinga, University of Twente
Wendi Heinzelman, University of Rochester
Sanjay Jha, UNSW, Sydney
Anupam Joshi, UMBC
Sneha Kasera, Utah
Young-Bae Ko, Ajou University
Robin Kravetz, UIUC
Bhaskar Krishnamachari, USC
Lakshman Krishnamurthy, Intel
Srikanth Krishnamurthy, UCR
Marwan Krunz, Arizona
P.R. Kumar, UIUC
Kevin Lai, HP
Koen Langendoen, Delft University of Technology
Bo Li, Hong Kong University of Science and Technology
Li Li, Bell Labs, Lucent Technologies
Mingyan Liu, Michigan
Richard Martin, Rutgers University
Seapahn Megerian, University of Wisconsin
Lynette Millett, The National Academies
Thyagarajan Nandagopal (Bell Labs, Lucent Technologies)
Peng Ning, NCSU
Charles Perkins, Nokia Research Center
Lili Qiu, Microsoft
Parmesh Ramanathan, University of Wisconsin
Jason Redi, BBN
Martin Reisslein, ASU
Paolo Santi, CNR
Andreas Savvides, Yale
Curt Schurgers, UCSD
Sergio Servetto, Cornell
Rajeev Shorey, NUS Singapore
Suresh Singh, Portland State Univ
Emin Sirer, Cornell University
Raghupathy Sivakumar, Georgia Tech.
Mani Srivastava, UCLA
John  Stankovic, University of Virginia
William Su, Boeing
Gaurav Sukhatme, USC
Yu-Chee Tseng, National Chiao-Tung Univ.
Cedric Westphal, Nokia
Stephen Wicker, Cornell
Adam Wolisz, Technical University of Berlin
Mark Yarvis, Intel Corporation
Qian Zhang, Microsoft Research Asia
Michele Zorzi, Universita'di Ferrara

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

Date: Thu, 29 Apr 2004 11:26:12 +0100
From: Stephen Farrell <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN architecture/implementation working meeting - Caltech 5-May-2004
Sender: [email-masked]

Kevin,

> Precisely.  I have requested an allocation for the upcoming IETF
> in August in San Diego (last day), but have not yet received confirmation.

V. good idea. But even if their schedule was full, we could still
arrange a day to meet there - there're always plenty of rooms/halls/bars
available, esp on the Friday am. So there's no need to wait. In any case
the IETF schedule is always very much in collision avoidance flux right
up to a week or two in advance - they deliberately arrange a week-long
meeting assuming most people stay most of the time, not a separate
series of day long meetings, with the result that knowing for sure
what day your meeting's only happens very near the time. So going right
ahead and announcoing a DTNRG meeting on the Thursday or Friday would be
fine with me!

> The meeting next week is really targeted for people with their hands
> in the guts of the reference implementation [but it is open].

I do understand that. Effectively though the meeting is not open to
me, due to the lack of notice. I think its just something one has
to get used to when there're many timezones involved - stuff just
has to be arranged further in advance to be fair to all. (Having said
that, I would much prefer to meet up in conjunction with an IETF
or some other conference, so given a choice I'd rather travel in
August. Meanwhile, I'll shut up now:-)

Stephen.

To: [email-masked]
Date: Wed, 28 Apr 2004 17:22:11 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] anyone know about this?
Sender: [email-masked]

Does anyone know any actual details about this:

http://www.microsoft.com/windowsmobile/products/pocketpcphone/about/2003/connections.mspx

- K

To: "Micah Beck" <[email-masked]>
cc: [email-masked]
Date: Wed, 28 Apr 2004 09:36:04 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] DARPA BAA?
Sender: [email-masked]

I have asked Preston a couple of times, and the answer I have received
to date is 'we are putting the final touches on it'.  However, that was
several weeks ago now.   So, no, unfortunately I do not know its
status.  It appears to be in some form of DARPA limbo.

- K

>
> From:  "Micah Beck" <[email-masked]>
> To:    "Kevin Fall" <[email-masked]>
> Subject: Re: [dtn-interest] DTN architecture/implementation working meeting -
	   Caltech 5-May-2004
> Date:  Wed, 28 Apr 2004 11:20:51 EDT
>
> Kevin,
> 
> Do you have any idea what happened to the DTN DARPA BAA?
> /micah

To: Stephen Farrell <[email-masked]>
cc: [email-masked]
Subject: Re: [dtn-interest] DTN architecture/implementation working meeting - Caltech 5-May-2004 
Date: Wed, 28 Apr 2004 09:33:44 -0700
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

>
> From:  Stephen Farrell <[email-masked]>
> To:    Kevin Fall <[email-masked]>
> cc:    [email-masked]
> Subject: Re: [dtn-interest] DTN architecture/implementation working meeting -
	   Caltech 5-May-2004
> Date:  Wed, 28 Apr 2004 15:58:47 BST
>
> 
> A week's notice! Sigh.
> 
> It'd be nice if in future meetings were arranged somewhat
> further in advance and ideally co-located with something
> else interesting (e.g. an IETF).

Precisely.  I have requested an allocation for the upcoming IETF
in August in San Diego (last day), but have not yet received confirmation.

The meeting next week is really targeted for people with their hands
in the guts of the reference implementation [but it is open].

- K

Date: Wed, 28 Apr 2004 15:58:47 +0100
From: Stephen Farrell <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN architecture/implementation working meeting - Caltech 5-May-2004
Sender: [email-masked]

A week's notice! Sigh.

It'd be nice if in future meetings were arranged somewhat
further in advance and ideally co-located with something
else interesting (e.g. an IETF).

Stephen.

PS: You're all invited to come here on May 6th for the
post-meeting beers:-)

Kevin Fall wrote:

> There will be a DTN get-together at Caltech next wednesday, nominally 9am-5pm.
> This day is targeted for resolving some of the issues surrounding
> regions, routing, and fragmentation, and to discuss the future evolution and
> usage of the DTN reference implementation.
> 
> If you wish to attend this get-together and have not already been in contact
> with me, please send me direct e-mail to synchronize.
> 
> Thanks,
> - Kevin
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

To: [email-masked]
Date: Tue, 27 Apr 2004 13:41:59 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] DTN architecture/implementation working meeting - Caltech 5-May-2004
Sender: [email-masked]

There will be a DTN get-together at Caltech next wednesday, nominally 9am-5pm.
This day is targeted for resolving some of the issues surrounding
regions, routing, and fragmentation, and to discuss the future evolution and
usage of the DTN reference implementation.

If you wish to attend this get-together and have not already been in contact
with me, please send me direct e-mail to synchronize.

Thanks,
- Kevin

Date: Sat, 24 Apr 2004 20:17:00 +0200
From: Andy Rabagliati <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Wizzy Digital Courier
Sender: [email-masked]

On Sun, 29 Feb 2004, Andy Rabagliati wrote:

> Folks,
> 
>   Here after your Slashdot publicity :-)

I notice you in my webstats too :-)

>   We have an Internet-content delivery system that works in a
>   high-latency environment, to deliver mail and web content to South
>   African schools.
> 
>   	http://wizzy.org.za/
> 
>   The problem it is designed to overcome is the high cost of local
>   telephone calls in a monopoly wireline provider regulatory
>   environment.
> 
>   We use cheap-rate overnight phone calls and a UUCP delivery system in
>   conjunction with a local mailserver and wwwoffle web cache.
> 
>   UUCP can also be used via a USB memory stick, similar to the DataMule
>   paper referenced on your website. Carrying the memory stick (the Courier)
>   is identical to one UUCP hop.
> 
>   The website gives more information.

Wizzy has had some recent publicity, at 

	http://www.wired.com/news/business/0,1367,63131,00.html

that you are welcome to make use of :-)

I really love the UUCP concept of simplicity, and extensibility.

Latency is like fax.

Cheers,  Andy!

From: "Keith Scott" <[email-masked]>
To: <[email-masked]>
Date: Thu, 22 Apr 2004 11:19:39 -0400
Organization: The MITRE Corporation
Subject: [dtn-interest] GNU punycode library
Sender: [email-masked]

http://freshmeat.net/projects/libidn/?branch_id=34389&release_id=158477

Date: Wed, 21 Apr 2004 21:39:41 -0400
From: Keith Scott <[email-masked]>
Subject: RE: [dtn-interest] Some basic questions...
To: [email-masked], [email-masked]
Organization: The MITRE Corporation
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Melissa Ho
> Sent: Monday, April 19, 2004 12:22 PM
> To: [email-masked]
> Subject: Re: [dtn-interest] Some basic questions...
> 
> > > DTN is a network of internets. DTN gateway connects these 
> internets. 
> > > The gateway speaks as many protocol stacks as the number of 
> > > internets
> > > (regions) it connects. Is it correct?
> > 
> > I believe so.
> 
> Mostly correct. A region can theoretically support more than 
> one protocol stack (the Internet region supports a lot), and 
> a gateway connecting regions only needs to support one 
> protocol per region that it interconnects, but has the option 
> of supporting more.

I think this is one of those things we're going to want to talk about.  I
suspect (not totally sure yet) that I'd go for the 'a region can support
multiple protocols' thesis only if _all_ bundle-capable devices in that
region support _all_ the protocols.  That is, say the internet region
supports TCP, UDP, and SCTP.  If you only require gateways into that region
to support ONE of the protocols, what happens when my region consists of
three gateways, one that talks into the region with TCP, one that talks into
it with UDP, and one that talks into it with SCTP?  Not really a region
then, I'd say.  And it's just yicky.  If the region has bundle routers 'in
the middle' (i.e. non-gateway bundle routers), each of which supports some
subset of the protocols in the region and you want to do intra-regional
routing, you're going to have to distribute information about who does what.
This sounds to me like its multiple regions.

> 
> Or in another scenario, all the regions may use the same 
> protocols, but be available at differing but slightly 
> overlapping times. So the gateway serves as store and forward 
> for coordination between schedules, but only supports one protocol.
> 

Right.

[snip]

From: "Vijay Velusamy" <[email-masked]>
To: <[email-masked]>
Date: Wed, 21 Apr 2004 12:55:02 -0500
Subject: [dtn-interest] CFP - Workshop on Scalable File Systems and Storage Technologies - PDCS 2004
Sender: [email-masked]

This is a multi-part message in MIME format.

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

        [[ -- Apologies for multiple copies of this message -- ]]

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D                  =
Call for Papers and Participation

       WORKSHOP ON SCALABLE FILE SYSTEMS AND STORAGE TECHNOLOGIES

                         in conjunction with

THE 17TH INTERNATIONAL CONFERENCE ON PARALLEL AND DISTRIBUTED COMPUTING =
SYSTEMS (PDCS 2004)

                          San Francisco, CA
                         September 15-17, 2004

http://multimedia.ece.uic.edu/pdcs2004/PDCS_WS_CFP.pdf

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Computational simulations generate vast amounts of data that require
distributed storage facilities to effectively store, retrieve, and share
the information among collaborating applications. Performance of such
simulations is impacted by the performance of the storage subsystem. =20
Storage technologies are also evolving drastically in order to keep up
with the ever-increasing demand for improved data access. Along with
complex simulations and associated storage come new challenges. The goal
of this workshop is to encourage innovation by addressing the complex  =20
issues that arise in data storage associated with very large-scale
distributed applications.  This one-day workshop promotes the exchange =
of
novel ideas, information and developments among universities, industry =
and
federal laboratories. Topics of interest of this workshop include (but =
are
not limited to) the illustration of advances in the following areas:

* Parallel File Systems :
* Storage Technology and protocols
* Storage issues in Grid computing environments
* Storage issues associated with large-scale distributed applications
* I/O Performance Analysis;
* Parallel I/O support for databases.

There will be several invited 30-minutes lectures as well as contributed
20-30 minutes talks. Accepted abstracts would be published in the
conference proceedings. Links to individual presenters materials will be
posted at http://ardra.hpcl.cis.uab.edu/sfast04/

To submit papers, send your manuscript (4 page extended abstract)
electronically (PS or PDF format, compressed) or by mail (3 paper =
copies)
to the following address:

Vijay Velusamy
High Performance Computing Laboratory
Department of Computer and Information Sciences
113A Campbell Hall, 1300 University Boulevard
Birmingham, AL 35294-1170
e-mail: [email-masked]

IMPORTANT DATES
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Submission deadline : June 4, 2004
Acceptance Notifications : July 5, 2004
Camera-ready prints : July 28, 2004

Invited Speakers:
* Garth Gibson (Carnegie Mellon University, Panasas, Inc.)               =
    =20
* Gary Grider (Los Alamos National Laboratories)                         =
   =20
* Tyce Mclarty (Lawrence Livermore National Laboratories)
* Thomas H. Cormen (Dartmouth College)
* Robert Ross (Argonne National Laboratories)

Steering Committee:
* Anthony Skjellum (University of Alabama at Birmingham)
* Vijay Velusamy (University of Alabama at Birmingham)
* Kumaran Rajaram (Verari Systems, Inc.)

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Vijay Velusamy

High Performance Computing Laboratory
Department of Computing and Information Sciences
University of Alabama at Birmingham
[email-masked]
------=_NextPart_000_00A3_01C4279F.DCBACED0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [[ -- Apologies for =
multiple=20
copies of this message --=20
]]<BR><BR>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
Call for Papers and Participation</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WORKSHOP ON SCALABLE FILE =
SYSTEMS AND=20
STORAGE TECHNOLOGIES</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
in conjunction with</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>THE 17TH INTERNATIONAL CONFERENCE ON PARALLEL AND DISTRIBUTED=20
COMPUTING&nbsp;SYSTEMS (PDCS 2004)</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;=20
San Francisco,=20
CA<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
September 15-17, 2004</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><A=20
href=3D"http://multimedia.ece.uic.edu/pdcs2004/PDCS_WS_CFP.pdf">http://mu=
ltimedia.ece.uic.edu/pdcs2004/PDCS_WS_CFP.pdf</A></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>Computational simulations generate vast amounts of data that=20
require<BR>distributed storage facilities to effectively store, =
retrieve, and=20
share<BR>the information among collaborating applications. Performance =
of=20
such<BR>simulations is impacted by the performance of the storage=20
subsystem.&nbsp; <BR>Storage technologies are also evolving drastically =
in order=20
to keep up<BR>with the ever-increasing demand for improved data access. =
Along=20
with<BR>complex simulations and associated storage come new challenges. =
The=20
goal<BR>of this workshop is to encourage innovation by addressing the=20
complex&nbsp;&nbsp; <BR>issues that arise in data storage associated =
with very=20
large-scale<BR>distributed applications.&nbsp; This one-day workshop =
promotes=20
the exchange of<BR>novel ideas, information and developments among =
universities,=20
industry and<BR>federal laboratories. Topics of interest of this =
workshop=20
include (but are<BR>not limited to) the illustration of advances in the=20
following areas:</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>* Parallel File Systems :<BR>* Storage Technology and =
protocols<BR>*=20
Storage issues in Grid computing environments<BR>* Storage issues =
associated=20
with large-scale distributed applications<BR>* I/O Performance =
Analysis;<BR>*=20
Parallel I/O support for databases.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>There will be several invited 30-minutes lectures as well as=20
contributed<BR>20-30 minutes talks. Accepted abstracts would be =
published in=20
the<BR>conference proceedings. Links to individual presenters materials =
will=20
be<BR>posted at <A=20
href=3D"http://ardra.hpcl.cis.uab.edu/sfast04/">http://ardra.hpcl.cis.uab=
.edu/sfast04/</A></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>To submit papers, send your manuscript (4 page extended=20
abstract)<BR>electronically (PS or PDF format, compressed) or by mail (3 =
paper=20
copies)<BR>to the following address:</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>Vijay Velusamy<BR>High Performance Computing =
Laboratory<BR>Department of=20
Computer and Information Sciences<BR>113A Campbell Hall, 1300 University =

Boulevard<BR>Birmingham, AL 35294-1170<BR>e-mail: <A=20
href=3D"mailto:[email-masked]">[email-masked]</A></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><BR>IMPORTANT=20
DATES<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>Submis=
sion deadline : June 4, 2004<BR>Acceptance=20
Notifications : July 5, 2004<BR>Camera-ready prints : July 28, =
2004</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>Invited Speakers:<BR>* Garth Gibson (Carnegie Mellon University, =
Panasas,=20
Inc.)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>*=20
Gary Grider (Los Alamos National=20
Laboratories)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>*=20
Tyce Mclarty (Lawrence Livermore National Laboratories)<BR>* Thomas H. =
Cormen=20
(Dartmouth College)<BR>* Robert Ross (Argonne National =
Laboratories)</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>Steering Committee:<BR>* Anthony Skjellum (University of Alabama at =

Birmingham)<BR>* Vijay Velusamy (University of Alabama at =
Birmingham)<BR>*=20
Kumaran Rajaram (Verari Systems, Inc.)</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>Vijay Velusamy</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>High Performance Computing Laboratory<BR>Department of Computing =
and=20
Information Sciences<BR>University of Alabama at Birmingham<BR><A=20
href=3D"mailto:[email-masked]">[email-masked]</A></DIV></=
BODY></HTML>

------=_NextPart_000_00A3_01C4279F.DCBACED0--

Date: Mon, 19 Apr 2004 14:20:51 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Some basic questions...
Sender: [email-masked]

At 12:48 PM 4/19/2004 +0100, Stephen Farrell wrote:

>Arun,
>
>>DTN is a network of internets. DTN gateway connects these internets. The
>>gateway speaks as many protocol stacks as the number of internets
>>(regions) it connects. Is it correct?
>
>I believe so.
>
>>         Now a DTN node is an end user node, where the bundling layer is
>>sitting between application and transport. Is this correct?
>
>I'm sure that that could generate lots of debate. I hope it doesn't:-)
>
>The main thing is that currently only the DTN gateways MUST have
>a DTN stack. For all other nodes YMMV, maybe your combination
>or regions/applications works better with DTN stacks everywhere,
>or maybe it doesn't, either way is ok, and can be invisible once
>you're on the other side of the DTN gateway.

I think we've started to use the term "node" to refer to any entity that 
speaks the Bundling protocol, whether in the immediate service of an 
application end user (either as sender or receiver) or in the capacity of a 
router (either between regions -- a "gateway" -- or within a single region).

>  Now, how does this end-user DTN node know the
>>address of the DTN gateway?
>
>That'd be region-specific. Probably either simple configuration
>or else destination-name/address based. Only you/your region
>cares.

And it depends on what is meant by "address".  The gateway has at least one 
DTN "address" (endpoint ID) that locates it within the DTN region, and it 
also has at least one address in an underlying network that enables 
transmission of bundles between nodes; for example, an IP address.

>>Next question: Consider a sensor network. There is a DTN gateway
>>connecting this sensor network to the Internet. But the gateway cannot
>>talk to the sensor nodes directly; it utilizes a datamule (which is in
>>contact with gateway for some time, and at a later time is in contact
>>with the sensor nodes).
>>My question is, in DTN context where does the role of datamule fit in?
>
>Actually, I've been modelling both IPNs and sensor networks and at
>least in my models, a datamule is almost the same as an Earth
>station, especially if the mule periodically contacts different
>sensor nets (planets). My main application has one sensor net/region
>per lake, and the mule is on a boat that could traverse >1 lake,
>so as the day goes and them mule sails down the river system, it
>"sees" different sensor nets. (Can't wait to get to testing this
>stuff! :-)

The datamule certainly functions as a DTN router, collecting bundles from 
some nodes and storing them and eventually forwarding them to other 
nodes.  We've had some heated discussions over the past few weeks on the 
question of how region boundaries are drawn, so at this point it's not 
clear if this datamule is an intra-regional router or a gateway into a 
datamules region.  Is that the answer you were looking for?

Scott 

Date: Mon, 19 Apr 2004 10:22:17 -0700
From: Melissa Ho <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: [dtn-interest] Some basic questions...
Sender: [email-masked]

> > DTN is a network of internets. DTN gateway connects these internets. The
> > gateway speaks as many protocol stacks as the number of internets
> > (regions) it connects. Is it correct?
> 
> I believe so.

Mostly correct. A region can theoretically support more than one
protocol stack (the Internet region supports a lot), and a gateway
connecting regions only needs to support one protocol per region that
it interconnects, but has the option of supporting more.

Or in another scenario, all the regions may use the same protocols,
but be available at differing but slightly overlapping times. So the
gateway serves as store and forward for coordination between
schedules, but only supports one protocol.

> 
> >       Now a DTN node is an end user node, where the bundling layer is
> > sitting between application and transport. Is this correct?
> 
> I'm sure that that could generate lots of debate. I hope it doesn't:-)
> 
> The main thing is that currently only the DTN gateways MUST have
> a DTN stack. For all other nodes YMMV, maybe your combination
> or regions/applications works better with DTN stacks everywhere,
> or maybe it doesn't, either way is ok, and can be invisible once
> you're on the other side of the DTN gateway.

A non-gateway DTN can theoretically use RPC to contact the bundling
layer on the gateway, and thus not really implement the DTN stack.

You're missing the convergence layer. See the bundling specification
on dtnrg.org for details.

+------------------------
|    application: This sends and receives data from the bundling layer
+------------------------
|    bundling: This puts bundles together, figures out where to send them, etc
+------------------------
|    convergence: This is the layer that "translates" between the
bundle layer and
|    one or more transport protocols.
+------------------------
|    transport: This is an already existing layer that gets data from one place
|    to another. It is independent and unaware of bundles.
+------------------------
|    ...

> 
>  > Now, how does this end-user DTN node know the
> > address of the DTN gateway?
> 
> That'd be region-specific. Probably either simple configuration
> or else destination-name/address based. Only you/your region
> cares.

Your DTN gateway could have an advertising mechanism, or it could be
hardcoded, or any other mechanism you can think of for it to figure it
out.

> 
> > Next question: Consider a sensor network. There is a DTN gateway
> > connecting this sensor network to the Internet. But the gateway cannot
> > talk to the sensor nodes directly; it utilizes a datamule (which is in
> > contact with gateway for some time, and at a later time is in contact
> > with the sensor nodes).
> >
> > My question is, in DTN context where does the role of datamule fit in?
> 
> Actually, I've been modelling both IPNs and sensor networks and at
> least in my models, a datamule is almost the same as an Earth
> station, especially if the mule periodically contacts different
> sensor nets (planets). My main application has one sensor net/region
> per lake, and the mule is on a boat that could traverse >1 lake,
> so as the day goes and them mule sails down the river system, it
> "sees" different sensor nets. (Can't wait to get to testing this
> stuff! :-)
> 

Check out DTN Lite, a project on dtn for sensor networks:
http://www.cs.berkeley.edu/~rkpatra/cs294_deep/deep_proj/deep_rabin_sergiu/

In terms of the role of the datamule, you have some freedom in how you
design your region.  If you have one sensor net, and one gateway, that
could all be in the same region. The data mule would be a dtn node
within this region, the gateway would be between the Internet and this
sensor net, and the sensor nodes also be dtn nodes that communicate
with the data mule whenever contact with it is available. If storage
is an issue on the sensors, you could have a separate storage dtn node
within range of the sensors that collects the data, with the mule
going between the storage node and the gateway.

Melissa

Date: Mon, 19 Apr 2004 12:48:03 +0100
From: Stephen Farrell <[email-masked]>
To: Arun Agrahara Somasundara <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Some basic questions...
Sender: [email-masked]

Arun,

> DTN is a network of internets. DTN gateway connects these internets. The
> gateway speaks as many protocol stacks as the number of internets
> (regions) it connects. Is it correct?

I believe so.

> 	Now a DTN node is an end user node, where the bundling layer is
> sitting between application and transport. Is this correct?

I'm sure that that could generate lots of debate. I hope it doesn't:-)

The main thing is that currently only the DTN gateways MUST have
a DTN stack. For all other nodes YMMV, maybe your combination
or regions/applications works better with DTN stacks everywhere,
or maybe it doesn't, either way is ok, and can be invisible once
you're on the other side of the DTN gateway.

 > Now, how does this end-user DTN node know the
> address of the DTN gateway?

That'd be region-specific. Probably either simple configuration
or else destination-name/address based. Only you/your region
cares.

> Next question: Consider a sensor network. There is a DTN gateway
> connecting this sensor network to the Internet. But the gateway cannot
> talk to the sensor nodes directly; it utilizes a datamule (which is in
> contact with gateway for some time, and at a later time is in contact
> with the sensor nodes).
> 
> My question is, in DTN context where does the role of datamule fit in?

Actually, I've been modelling both IPNs and sensor networks and at
least in my models, a datamule is almost the same as an Earth
station, especially if the mule periodically contacts different
sensor nets (planets). My main application has one sensor net/region
per lake, and the mule is on a boat that could traverse >1 lake,
so as the day goes and them mule sails down the river system, it
"sees" different sensor nets. (Can't wait to get to testing this
stuff! :-)

Hope that helps,
Stephen.

Date: Sun, 18 Apr 2004 15:32:25 -0700 (PDT)
From: Arun Agrahara Somasundara <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Some basic questions...
Sender: [email-masked]

I had some basic questions on DTN architecture. Below, i will write my
understanding, followed by questions.

DTN is a network of internets. DTN gateway connects these internets. The
gateway speaks as many protocol stacks as the number of internets
(regions) it connects. Is it correct?
	Now a DTN node is an end user node, where the bundling layer is
sitting between application and transport. Is this correct?
	Consider this node in Internet region. 2 cases arise:
	- if this node wants to communicate with another node in same
region (Internet), fine.
	- if this node wants to communicate with another node in some
other region, this message has to be first forwarded to the DTN gateway.
For this, routing functionality of the region it is present in is used (IP
as it is in Internet). Now, how does this end-user DTN node know the
address of the DTN gateway?

Next question: Consider a sensor network. There is a DTN gateway
connecting this sensor network to the Internet. But the gateway cannot
talk to the sensor nodes directly; it utilizes a datamule (which is in
contact with gateway for some time, and at a later time is in contact
with the sensor nodes).

My question is, in DTN context where does the role of datamule fit in?

Thanks,
Arun

To: [email-masked]
Date: Tue, 13 Apr 2004 18:23:55 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] web site updated
Sender: [email-masked]

I've updated the dtnrg web site with a few new things, including a proposed rev to
the bundle protocol spec, a version of bundle daemon docs from Keith Scott, and
some links to some other related projects.

enjoy,
- K

Date: Tue, 13 Apr 2004 13:46:43 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] more ltp comments
Sender: [email-masked]

At 08:29 PM 4/13/2004 +0100, Stephen Farrell wrote:

>Scott,
>
>(I get back after a nice long weekend and what do I find... ;-)
>
>>Ah, this may be where we've gotten disconnected.  The data segments are 
>>likewise not self-delimiting: they contain client service data offset (an 
>>SDNV) but not client service data length.  That is why I've been saying 
>>this is a more general problem.
>
>A BIG oops! You're right, I missed that entirely.
>
>However, I'd stick to my (now weakened:-) guns in any case and
>would regard "DS/RS truncation" as an open issue in its own
>right, (fixable by e.g. adding a segment length field), in
>addition to the more general "what lower layer characteristics
>are REQUIRED?" issue which we both agree needs addressing.
>
>I don't want to prolong the discussion now, but I can't resist
>noting the following behaviour of the protocol, so this is just
>for the archive: DS truncation as I now properly understand it,
>is just like loss of an entire segment and is recovered from
>using the RS mechanism. Almost all cases of truncation of an RS
>will cause that RS to decode incorrectly due to SDNV's inclusion
>of a length field in the offsets & lengths of the data reception
>claims. But, the occasional unlucky truncation of an RS at a
>data claim reception (offset/length) boundary, causes the
>recipient of the RS to assume the loss of some bytes that were
>in fact received (since the upper bound is at the start of the
>RS), thus causing re-transmission of those bytes, which seems
>like an unintended side effect that'd be fairly hard to debug
>when it does inevitably happen.

Absolutely.  I certainly agree that we need a way to detect RS truncation, 
but my preference is for a more general mechanism that detects all segment 
truncations: either a segment content length field in the segment header or 
else a requirement imposed on the lower layer protocol.

I'm inclined to go with the latter because it saves us a few bytes on every 
single segment.  On the other hand, I have got to allow that the CFDP 
design includes both a content length field in the PDU header and also an 
optional CRC on every PDU.  These are CFDP design features that I was 
hoping we could get away from by demanding a bit more from the underlying 
link layer protocols, but perhaps that's unrealistic.

>Lastly, since I re-read the RS bit (7.2.2), I noticed a new nit:
>Though I had assumed that the data receiption claims would be
>"sorted" and "sane" there's no actual requirement in the spec
>for that, e.g. the spec appears to allow an RS like:
>
>upper bound: 0 // silly upper bound
>lower bound: 10000 // lower > upper
>         claim1: offset: 1000, length 0 // silly length?
>         claim2: offset: 0, length 100  // offset out of order
>         claim3: offset: 100, length 99 // this overlaps...
>         claim4: offset: 140, length 40 // ...with this
>
>And also:
>
>upper bound: 6000
>lower bound: 0
>         claim5: offset: 5999, length 20 // offset+length >= upper bound
>         claim6: offset: 10000, length 55 // offset >= upper bound
>         claim7: offset: 6000, length 0 // loss of entire scope?
>
>The spec should probably make clear what's allowed there and
>what some of those corner cases mean when/if they are allowed.
>My take would be to disallow all such silly claims, except maybe
>the last one (claim7) where its the one and only claim in the RS.
>However I've no text to offer right now that'd have that effect.

Good point.  I think we want to say something like...

"Reception claims MUST conform to the following rules:
-       A reception claim's offset shall never be less than zero and its 
length shall never be less than 1.
-       The offset of a reception claim shall always be greater than the 
sum of the offset and length of the prior claim, if any.
-       The sum of a reception claim's offset and length shall never exceed 
the difference between the upper and lower bounds of the report segment."

>Regardless, the spec should tell an implementer how to handle such
>an RS if it does get one (maybe just ditch the RS in /dev/null and
>wait for some longer timer to expire).

I think that should be covered by our blanket statement on invalid values 
in header fields (interpret as a bit hit, which should cause the segment to 
be discarded immediately without further processing).

Scott 

Date: Tue, 13 Apr 2004 20:29:08 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] more ltp comments
Sender: [email-masked]

Scott,

(I get back after a nice long weekend and what do I find... ;-)

> Ah, this may be where we've gotten disconnected.  The data segments are 
> likewise not self-delimiting: they contain client service data offset 
> (an SDNV) but not client service data length.  That is why I've been 
> saying this is a more general problem.

A BIG oops! You're right, I missed that entirely.

However, I'd stick to my (now weakened:-) guns in any case and
would regard "DS/RS truncation" as an open issue in its own
right, (fixable by e.g. adding a segment length field), in
addition to the more general "what lower layer characteristics
are REQUIRED?" issue which we both agree needs addressing.

I don't want to prolong the discussion now, but I can't resist
noting the following behaviour of the protocol, so this is just
for the archive: DS truncation as I now properly understand it,
is just like loss of an entire segment and is recovered from
using the RS mechanism. Almost all cases of truncation of an RS
will cause that RS to decode incorrectly due to SDNV's inclusion
of a length field in the offsets & lengths of the data reception
claims. But, the occasional unlucky truncation of an RS at a
data claim reception (offset/length) boundary, causes the
recipient of the RS to assume the loss of some bytes that were
in fact received (since the upper bound is at the start of the
RS), thus causing re-transmission of those bytes, which seems
like an unintended side effect that'd be fairly hard to debug
when it does inevitably happen.

Lastly, since I re-read the RS bit (7.2.2), I noticed a new nit:
Though I had assumed that the data receiption claims would be
"sorted" and "sane" there's no actual requirement in the spec
for that, e.g. the spec appears to allow an RS like:

upper bound: 0 // silly upper bound
lower bound: 10000 // lower > upper
	claim1: offset: 1000, length 0 // silly length?
	claim2: offset: 0, length 100  // offset out of order
	claim3: offset: 100, length 99 // this overlaps...
	claim4: offset: 140, length 40 // ...with this

And also:

upper bound: 6000
lower bound: 0
	claim5: offset: 5999, length 20 // offset+length >= upper bound
	claim6: offset: 10000, length 55 // offset >= upper bound
	claim7: offset: 6000, length 0 // loss of entire scope?

The spec should probably make clear what's allowed there and
what some of those corner cases mean when/if they are allowed.
My take would be to disallow all such silly claims, except maybe
the last one (claim7) where its the one and only claim in the RS.
However I've no text to offer right now that'd have that effect.
Regardless, the spec should tell an implementer how to handle such
an RS if it does get one (maybe just ditch the RS in /dev/null and
wait for some longer timer to expire).

Stephen.

Date: Thu, 08 Apr 2004 10:30:39 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] more ltp comments
Sender: [email-masked]

At 05:48 PM 4/8/2004 +0100, Stephen Farrell wrote:

>Scott,
>
>>This refinement bothers me a little, because I can well imagine a mixture 
>>of SDNV-8 and SDNV-16 fields being the most efficient way to construct an 
>>LTP segment.
>
>Granted.
>
> > Report and checkpoint serial numbers should
>>virtually never exceed 127;
>
>Depends - for anti-DoS reasons you may not want to start at 0.
>But that is still TBD.
>
> > nor should session originator (engine ID;
>>remember, LTP doesn't see a large network), client service ID, or (for 
>>the foreseeable future) expansion zone.  But client service data offset 
>>in data segments and the bounds and reception claim fields in report 
>>segments might very often be values in the range that an SDNV-16 would 
>>encode more efficiently than an SDNV-8.  Why not define these fields in 
>>this way once and for all in the protocol spec, and always construct and 
>>parse them the same way?
>
>Where that makes sense, I've no problem doing so. If it turns out t
>that that makes sense for all fields all the time, then that's fine
>too and there's no need for the additional trick.
>
>But, if there are (groups of) fields left over where the analysis
>says "sometimes 5 bits, sometimes 12 bits, depending on the
>environment", then I think the trick is worthwhile in terms of
>overall segment length (and its easy to code up, which I always
>like:-). I suspect, without any good evidence whatsoever, that
>there are many such fields since the sizing will depend on buffer
>sizes etc. which will vary by equipment/environment.
>
> > Implementation is simplified a little, and we
>>don't consume an additional bit in the control byte.
>
>True. Though consuming that bit is a future-proofing, not
>a bandwidth consumption, issue.
>
>Overall, I'm quite happy to leave this to testing/experience, so
>maybe best for now would be to document it as a "we might add this
>back if its really useful" kind of feature in the published I-D.

Fair enough, let's do that.

>>>PS: Now can I have my "number of offset/length" pairs byte in
>>>the RS? :-)
>>Seriously, Stephen, if we couldn't rely on the underlying link protocol 
>>telling us the size of the delivered LTP segment then I think we'd need 
>>all LTP segments to be self-delimiting --
>
>I think they all are - except the RS. If I'm wrong on that then the
>specific "truncated RS" argument does fall, and we're back to the
>general "which lower layers" issue as you said.

Ah, this may be where we've gotten disconnected.  The data segments are 
likewise not self-delimiting: they contain client service data offset (an 
SDNV) but not client service data length.  That is why I've been saying 
this is a more general problem.

>>we would need segment size in the header.
>
>Nope. Since they all (except the RS) effectively have a fixed
>set of fields, all of which are fixed width or SDNV.

Right, except that client service data in the data segment is neither.

> > Once you know total segment size, parsing out the data
>>reception claims in an RS should be no problem.  [Anyway, given that the 
>>data reception claims are variable-length (both offset and length are 
>>SDNVs), I don't see how simply knowing the number of claims in the RS 
>>would be helpful.  Am I missing something?]
>
>Let me try restate the issue and it might be more compelling.
>
>1. The problem is the "truncated RS" problem. *All* other LTP segment
>definitions (as far as I can see) are such that the LTP layer can
>tell by looking if the segment was truncated or not.

Okay, maybe I'm missing something.  How are you figuring you can determine 
the length of a data segment by inspection?

>The RS is the
>*only* exception since its the only segment that has a "sequence of"
>construct, but it doesn't have a "sequence length" field.
>
>2. The lower layer does indeed have to be trusted to tell us the
>length of the packet its just delivered to LTP. But, in general, and
>in some real world cases, that packet length does not have to
>represent a full LTP segment - due to lower layer fragmentation.
>Thus the packet can be a "full" lower layer packet, but not a "full"
>LTP segment.

You're saying (I think) that the lower layer protocol can in some cases 
deliver the payload/content of a complete lower-layer packet when that 
complete lower-layer packet is actually a fragment, and that therefore the 
delivered payload/content is not a complete application data unit.

That sounds like a totally busted lower-layer protocol implementation to me 
-- why isn't it invisibly reconstructing the original packet from 
fragments?  why is it exposing its fragmentation to the layer above without 
specific authorization from that layer? -- but I will stipulate that busted 
implementations of things do exist.  In the event that we need to run LTP 
over such an implementation, and the LTP header does not contain segment 
length, we do indeed have the problem you're talking about.

>3. Fixing the "truncated RS" problem (and just that) requires one
>additional byte in the RS payload part of the segment. That byte
>can represent the number of offset/length pairs in the RS. Where
>necessary (if there are more than 255 offset/length pairs) multiple
>RS segments are used in the obvious way. This is a simple, obvious
>and, IMO, prudent thing to do.

It would certainly be a way to solve this problem.

>Assuming I'm right that the RS is the only segment with this problem,

Which I think is the crux of the matter.

>then we seem to be disagreeing like this:
>
>10: Stephen: Lower layer packet size is not necessarily LTP segment size
>20: Scott: Oh yes it is - if I only use lower layers that make this so
>20: Stephen: But that's not always true.
>40: Scott: goto 20

Yes, that's pretty much it.  I think it is okay to say in the LTP spec that 
LTP SHALL only be used over link-layer protocols that meet the following 
minimum service requirements, and you assert that it is not.  And I think 
we're still listening for views from other readers on this list, if we 
haven't already driven them all away.

>PS: Today I came across something that implied that this could
>happen when using ethernet across a wireless hop (not that I'm
>quite sure I see how that configuration can arise). The situation
>posed was hosts A,B and C where A-B is a wireless link and B-C is
>wired; so B is some sort of wireless gateway as well as a host; but
>A,B and C are all on the same "LAN" - basically, the path MTU will
>be different from A and C's perspectives so that an ethernet
>packet from A->C may be fragmented. I'm not claiming this is a real
>world situation, but I have seen that claim...
>
>...goes looking again...
>
>...I went looking again but couldn't find the page about this. I did
>find the thing linked below [1] which looks like a product that might
>cause similar kinds of stuff to happen:
>
>[1] http://www.allmatics.com/presentaties/Smartnet/ethernetclient.pdf

I am fully prepared to agree that this kind of misbehavior is possible if 
you run LTP over certain kinds of (bizarre, I think) link systems.  But I 
figure it's like the old joke, one of my favorites:

Patient:  Doctor, doctor, it hurts when I do this.  (Hyperextends elbow.)

Doctor:   Right, don't do that.

Scott 

Date: Thu, 08 Apr 2004 18:27:02 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] more ltp comments
Sender: [email-masked]

One more thing about truncated RS and then I'm off for the
long weekend.

The problem can also happen this way, assuming a sockets-like
api with UDP-ish usage for clarity.

- A device wants to send an RS.
- It constructs the RS header, down to the 1st offset/length
   and sends that immediately via a sendto() equivalent.
- It then sends each offset/length via a separate call to the
   sendto() equivalent.
- Most likely is that the 1st recvfrom() gives the header and
   that an additional recvfrom() is required for each subsequent
   offset/length pair.

I've seen this kind of thing happen in e.g. HTTP code due to
different bits of code handling the headers and body (esp.
for POST requests and all responses, and more esp. inside
proxies, which have to work in-line).

I believe that doing the above would be silly, should be
conformant, and wouldn't work for the RS since the receiver
can't know when to stop interpreting the output from its
recvfrom() equivalent as RS payload bytes.

This silly, conformant, way of transmitting would however, work
fine for all other LTP segments since the receiver can parse out
the stuff from the recvfrom() calls.

But if we add that byte to RS then we're ok.

Convinced?
Stephen.

Date: Thu, 08 Apr 2004 17:48:40 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] more ltp comments
Sender: [email-masked]

Scott,

> This refinement bothers me a little, because I can well imagine a 
> mixture of SDNV-8 and SDNV-16 fields being the most efficient way to 
> construct an LTP segment.  

Granted.

 > Report and checkpoint serial numbers should
> virtually never exceed 127; 

Depends - for anti-DoS reasons you may not want to start at 0.
But that is still TBD.

 > nor should session originator (engine ID;
> remember, LTP doesn't see a large network), client service ID, or (for 
> the foreseeable future) expansion zone.  But client service data offset 
> in data segments and the bounds and reception claim fields in report 
> segments might very often be values in the range that an SDNV-16 would 
> encode more efficiently than an SDNV-8.  Why not define these fields in 
> this way once and for all in the protocol spec, and always construct and 
> parse them the same way?  

Where that makes sense, I've no problem doing so. If it turns out t
that that makes sense for all fields all the time, then that's fine
too and there's no need for the additional trick.

But, if there are (groups of) fields left over where the analysis
says "sometimes 5 bits, sometimes 12 bits, depending on the
environment", then I think the trick is worthwhile in terms of
overall segment length (and its easy to code up, which I always
like:-). I suspect, without any good evidence whatsoever, that
there are many such fields since the sizing will depend on buffer
sizes etc. which will vary by equipment/environment.

 > Implementation is simplified a little, and we
> don't consume an additional bit in the control byte.

True. Though consuming that bit is a future-proofing, not
a bandwidth consumption, issue.

Overall, I'm quite happy to leave this to testing/experience, so
maybe best for now would be to document it as a "we might add this
back if its really useful" kind of feature in the published I-D.

>> PS: Now can I have my "number of offset/length" pairs byte in
>> the RS? :-)
> 
> Seriously, Stephen, if we couldn't rely on the underlying link protocol 
> telling us the size of the delivered LTP segment then I think we'd need 
> all LTP segments to be self-delimiting -- 

I think they all are - except the RS. If I'm wrong on that then the
specific "truncated RS" argument does fall, and we're back to the
general "which lower layers" issue as you said.

> we would need segment size in 
> the header.  

Nope. Since they all (except the RS) effectively have a fixed
set of fields, all of which are fixed width or SDNV.

 > Once you know total segment size, parsing out the data
> reception claims in an RS should be no problem.  [Anyway, given that the 
> data reception claims are variable-length (both offset and length are 
> SDNVs), I don't see how simply knowing the number of claims in the RS 
> would be helpful.  Am I missing something?]

Let me try restate the issue and it might be more compelling.

1. The problem is the "truncated RS" problem. *All* other LTP segment
definitions (as far as I can see) are such that the LTP layer can
tell by looking if the segment was truncated or not. The RS is the
*only* exception since its the only segment that has a "sequence of"
construct, but it doesn't have a "sequence length" field.

2. The lower layer does indeed have to be trusted to tell us the
length of the packet its just delivered to LTP. But, in general, and
in some real world cases, that packet length does not have to
represent a full LTP segment - due to lower layer fragmentation.
Thus the packet can be a "full" lower layer packet, but not a "full"
LTP segment.

3. Fixing the "truncated RS" problem (and just that) requires one
additional byte in the RS payload part of the segment. That byte
can represent the number of offset/length pairs in the RS. Where
necessary (if there are more than 255 offset/length pairs) multiple
RS segments are used in the obvious way. This is a simple, obvious
and, IMO, prudent thing to do.

Assuming I'm right that the RS is the only segment with this problem,
then we seem to be disagreeing like this:

10: Stephen: Lower layer packet size is not necessarily LTP segment size
20: Scott: Oh yes it is - if I only use lower layers that make this so
20: Stephen: But that's not always true.
40: Scott: goto 20

Still looking for that extra byte,
Stephen.

PS: Today I came across something that implied that this could
happen when using ethernet across a wireless hop (not that I'm
quite sure I see how that configuration can arise). The situation
posed was hosts A,B and C where A-B is a wireless link and B-C is
wired; so B is some sort of wireless gateway as well as a host; but
A,B and C are all on the same "LAN" - basically, the path MTU will
be different from A and C's perspectives so that an ethernet
packet from A->C may be fragmented. I'm not claiming this is a real
world situation, but I have seen that claim...

...goes looking again...

...I went looking again but couldn't find the page about this. I did
find the thing linked below [1] which looks like a product that might
cause similar kinds of stuff to happen:

[1] http://www.allmatics.com/presentaties/Smartnet/ethernetclient.pdf

To: Stephen Farrell <[email-masked]>
cc: Howard Weiss <[email-masked]>, Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] fragmentation and erasure coding in Bundling + q on ecc 
Date: Thu, 08 Apr 2004 09:43:57 -0700
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

>
> From:  Stephen Farrell <[email-masked]>
> To:    Howard Weiss <[email-masked]>
> cc:    Kevin Fall <[email-masked]>,
	 Scott Burleigh <[email-masked]>,
	 [email-masked]
> Subject: Re: [dtn-interest] fragmentation and erasure coding in Bundling + q 
	  on ecc
> Date:  Thu, 08 Apr 2004 12:19:58 BST
>
> 
> > I do remember reading about some of the shortfalls of the technology - 
> > if memory serves me correctly, the server generates all the private keys 
> > so the TTP doesn't go away (and can act as a key escrow agent, which can 
> > be both good or bad depending on your environment), and because the 
> > sender of a message can be anonymous, identity is refutable.
> 
> Yes. Put another way, IBC inherently involves key escrow, and that's
> true for all IBC schemes, not just Boneh's (which is afaik by far
> the most elegant to date).
> 
> However, I do think there are DTN applications of IBC, especially
> if you buy into the region concept a lot - seems like crypto
> applied to bundles which are aimed at a region could well use IBC
> (where the "identity" being used to encrypt is effectively the
> destination region) if there were some prior inter-regional
> agreements in place. That makes regions more like administrative
> boundaries though, rather than the current region model which I
> think of as more geographical.
> 
> Kevin - how were you thinking of applying IBC?

I had a student working on this last summer and we have a (drafty)
paper on the topic.  I'm updating it presently.  But the
quick upshot is this--

In IBC (assuming I grasp this properly)
you sort of generate reliable public keys "on-the-fly" as needed.
That is good in the sense that 1> you don't have to store keys
for all the guys you might someday talk to and 2> you may be
able to avoid having to send along your own public key
when you talk to somebody new {that one sort of depends}.
The downside is the key generator, which, in a DTN, you
may not be able to get to.  So, you would presumably be forced
to pre-generate all the privates and install them in your
not-well-connected device.  If you have a PKG that you can
get to, then you are in better shape... you just need a secured
channel to it.

- K

Date: Thu, 08 Apr 2004 09:41:40 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] fragmentation and erasure coding in Bundling
Sender: [email-masked]

At 06:05 PM 4/7/2004 +0000, Melissa Ho wrote:
> > >I would prefer keeping it to single level fragmentation, which is in
> > >keeping with the protocol spec.
> >
> > I think the protocol spec says you can fragment a bundle, not that you can
> > only fragment a non-fragmentary bundle.  If so, the spec already supports
> > multi-level fragmentation.
>
>That's not what I meant.  You can fragment a fragmented bundle, but the
>resulting bundles are all single level fragments - they are not seen as
>fragments of fragments.  Here's the text from the spec - let me know if I've
>misread it:
>
>-- begin snippet
>4.3.1 Bundle Fragmentation
>... (skip to second point) ...
>* In addition to the original headers, each bundle fragment MUST containa
>fragment header identifying the fragmentary payload's position within the
>original payload and the length of the original (unfragmented) bundle's
>payload. Note that there is only one 'level' of fragmentation (as in IP
>fragmentation).
>-- end snippet

Okay, I agree, the fragments you get when you split up a fragment are 
encoded as (smaller) fragments with reference to the original bundle, not 
as fragments with reference to the original fragment.  The difference, I 
suppose, is that the fragments' headers contain information that enables 
you to reassemble the original payload from them, but not any information 
that would enable you to reassemble any particular fragment.

> > >Oh so "bindling" is actually a word and not a misspelling.  I would say
> > >this is not a profound architectural change - just a gray area that hadn't
> > >been implemented and now needs clarification.
> >
> > Except that I think it's currently not a gray area at all: you take 
> custody
> > of bundles, period.  If the bundle happens to be a fragmentary bundle,
> > well, okay, you're taking custody of a fragmentary bundle; the previous
> > custodian needs to recognize this by replicating the fragmentation after
> > the fact (if necessary) and releasing custody of the fragment 
> identified in
> > the custody ack.
>
>This is where I think the spec needed the section on what happens when you
>receive custody ACKs, bundle receipts, etc.  In its absence, it made sense to
>me that the previous custodian holds on to the entire bundle until its
>constituent fragments have all been ACKed individually. As far as I can tell,
>you believe that when the bundle agent decides to fragment a bundle, it
>replaces its copy of the bundle with the fragments, and then manages it from
>there.

You're right, this was never made explicit in the protocol spec, and in 
fact it may not have been (and may not be) everybody's understanding.  But 
I do think it's the simplest and most efficient way to handle this sort of 
behavior.

>I can see there's a valid argument for that point of view, and it makes 
>sense,
>even if it violates my instinct that distributed custody is just a bad idea.
>
>Here's a question: Where in the protocol should the decision of where to
>fragment the bundle to occur? Based on our conversations, it is:
>a) In the convergence layer - all fragmentation is reactive  --or--

Actually, here I think I would say "In 'Step 5. Forward the bundle' (i.e., 
within bundling) as advised by the CL - all bundle fragmentation is 
reactive".  But I know Kevin and I differ on this point.

>b) In the convergence layer - the CL should handle the breaking of bundles
>across multiple upcoming contacts, not the bundle routing

I'm know I'm repeating myself, but I don't see (a) and (b) as mutually 
exclusive.  Chopping a bundle into small pieces (as necessary) for 
transmission over convergence layer protocols within a region has always 
been a fundamental principle of the DTN architecture; the reference 
implementation already does this, using TCP.  As we get further into real 
applications I'm starting to propose DF/DTN tunneling as one of those 
convergence layer protocols, but the principle is exactly the same.

>c) In Step 5. Forward the bundle
>
>If the answer is (a) or (b), then the argument is more fundamental. But if it
>is (c), I suggest the following changes to the protocol spec:
>* Change Step 4c to read "hop(s)" instead of "hop"
>* Add a point to Step 4c as follows:
>   o If the next hop's upcoming contact is not long enough to send the entire
>bundle, then the agent MAY choose a set of next hops over which to send the
>bundle as fragments. The agent can choose a set of contacts over the same
>next hoop, or a set of contacts over different hops.
>* Introduce a Step 4d as follows:
>Step 4d: Fragment the bundle if necessary.
>o If the bundle is going out on multiple contacts, then it must be fragmented
>prior to being forwarded. The bundle fragments MUST adhere to the
>specification defined in section 4.3.1
>o If the bundle agent has custody of this bundle, it MUST assume custody of
>the fragments as in Step 4b, remove the original bundle from its persistent
>storage, and remove the retransmission timer for the original bundle. It does
>NOT need to send another acknowledgement to the previous custodian.
>(actually.... rather than referring to 4b, you might just rewrite relevant
>portions, to explain how to split custody)
>* Change Step 5 to read "bundle(s)" instead of "bundle" and "adapter(s)"
>instead of "adapter"

Thanks, let me look at the text again in the light of what we're saying here.

> > I believe that too.  I just don't think that means that erasure coding has
> > to be built into the bundling protocol.
>
>Certainly the bundling protocol will not die just because it doesn't have
>erasure coding. At the same time, I think erasure coding adds valuable
>functionality to the bundling protocol. It's no more complex than custodial
>transfer.
>
> > It doesn't bother me that bundling might end up quite small and simple if
> > we leave DF out of it; I like small and simple, it often means "working".
>
>Erasure coding is smaller and simpler than you probably realize.  The open
>source code I have less than 2000 lines, and can easily be smaller if I
>reduce it to just the encoder and decoder.
>
>Yes, it introduces some angles to DTN that may not be applicable in all
>situations. However, given that this is an architecture targeted towards
>*unreliable* networks, I think we should include mechanisms that address
>reliability. I do agree in that these mechanisms should be small and simple
>solutions.
>
> > We certainly don't want bundling to be so generalized that it doesn't do
> > anything useful.  But if bundling does nothing but deferred transmission,
> > store-and-forward, trans-regional routing, and options for inter-node
> > suspicion, custody transfer, congestion control, resilient delivery,
> > payload security, and some priority and reporting features, then I 
> think it
> > is doing quite a lot of useful stuff.  Let's do some other useful stuff
> > somewhere else.
>exactly. erasure coding is part of doing resilient delivery.

We've been using the term "resilient delivery" to talk about measures for 
assuring delivery to the destination endpoint ID (application), not 
measures for reliable forwarding -- things like application reanimation.

Certainly I don't want to understate the importance of including in the DTN 
architecture mechanisms for assuring reliability.  But in order to be able 
to tolerate long and possibly unpredictable delays in end-to-end 
transmission paths, we have generally moved away from reliance on 
end-to-end reliability mechanisms and toward point-to-point mechanisms 
enabling incremental (custodial) reliable advance toward the 
destination.  I have always argued against relying heavily on bundle-layer 
custodial retransmission because of the difficulty of getting 
retransmission timer intervals right and the costs of getting them 
wrong.  What has always seemed to me to be our best defense against data 
loss is to use whatever reliability mechanisms are provided by 
convergence-layer protocols, because those mechanisms will be designed to 
operate successfully in the specific kinds of environments in which we are 
using those protocols.

I fully recognize that erasure coding is valuable, and I am delighted that 
its implementations are small and simple.  Let's use it.  But why do we 
have to make it a built-in feature of the bundling protocol?  If there are 
numerous deployment environments in which it adds no value (which I am 
pretty sure there are) and if integrating it into bundling will add 
complexity to the protocol (which the email traffic on this thread amply 
demonstrates that it will), what is the advantage in putting it in bundling 
rather than in a convergence-layer protocol for regions that need it?

Scott 

Date: Thu, 08 Apr 2004 08:29:37 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] more ltp comments
Sender: [email-masked]

At 11:56 AM 4/7/2004 +0100, Stephen Farrell wrote:
>>>PS: Meanwhile, I've just noticed that each and every offset and length
>>>field in an RS is an SDNV, and hence has its own length field requiring 
>>>an additional byte for each, (assuming offsets & lengths would
>>>be expected to be >127). So I think that the encoding of RS segments
>>>isn't actually that parsimonious, which further argues for the
>>>additional byte required to distinguish complete vs. truncated RS
>>>segments. (As an aside, you could define a new type "SDNV-16" which
>>>works like an SDNV but where the MSB being clear means that the
>>>remainder of the 2-byte-fixed-size field is a value, and where the
>>>MSB being set means that its handled like a current SDNV. You could
>>>also have an SDNV-32, etc. and then depending on the likely values,
>>>using those types can save you some bytes in RS segments and maybe
>>>elsewhere. Not sure if that'd be worthwhile, was it considered
>>>already?)
> >
>>No, it wasn't, and I think it's a terrific idea.
>
>Yeah, I think I like it too! Thinking further what I think
>I'd do is the following:
>
>Define a new bit in the control byte which determines whether
>this segment is using SDNV-8 (unsigned version, otherwise as
>in current draft) or else SDNV-16 (as above). All SDNV fields
>in that segment are then encoded accordingly. There is no mixing
>of SDNV-8 and SDNV-16 in a single segment. Then the receiver
>has to be able to handle either, but that's no big deal. The
>transmitter can choose which to send at its discretion. In my
>code I'd probably take the dumb approach and encode both ways
>and then just send the shorter buffer - I'd give that as an
>example in the spec too.

This refinement bothers me a little, because I can well imagine a mixture 
of SDNV-8 and SDNV-16 fields being the most efficient way to construct an 
LTP segment.  Report and checkpoint serial numbers should virtually never 
exceed 127; nor should session originator (engine ID; remember, LTP doesn't 
see a large network), client service ID, or (for the foreseeable future) 
expansion zone.  But client service data offset in data segments and the 
bounds and reception claim fields in report segments might very often be 
values in the range that an SDNV-16 would encode more efficiently than an 
SDNV-8.  Why not define these fields in this way once and for all in the 
protocol spec, and always construct and parse them the same 
way?  Implementation is simplified a little, and we don't consume an 
additional bit in the control byte.

>Cleverer code might be able to do this with less CPU but the
>above ie enough for me.
>
>Given that a lot of SDNV fields represent lengths (bounds,
>offsets, lengths) and blocks are probably of the order of ~1kb,
>(~10bits for a length) then this should save a good bit over
>the entire segment, since we save 33% on encoding such values.

I agree, this could save a lot of transmission in the long run.  A great idea.

>On reflection, I also think there's no need to have more than
>two SDNV's (-8 and -16), since a) there probably aren't that many
>values in the [2^16,2^31) range that LTP is handling, b) we'd
>need more than one header bit to flag its use, c) with more
>variations the case for mixing the different types in a single
>segment might seem more compelling, but that adds code
>complexity, d) SDNV-16 can save 33% for a value compared to
>SDNV-8, but SDNV-32 saves much less if used everywhere
>(there'll definitely be values in the [0,2^15] range in
>all segments), and, e) some other reason someone else can
>provide:-)

(d) sounds most compelling to me.  I agree, SDNV-8 and SDNV-16 seem like 
enough for LTP's purposes.

>PS: Now can I have my "number of offset/length" pairs byte in
>the RS? :-)

Seriously, Stephen, if we couldn't rely on the underlying link protocol 
telling us the size of the delivered LTP segment then I think we'd need all 
LTP segments to be self-delimiting -- we would need segment size in the 
header.  Once you know total segment size, parsing out the data reception 
claims in an RS should be no problem.  [Anyway, given that the data 
reception claims are variable-length (both offset and length are SDNVs), I 
don't see how simply knowing the number of claims in the RS would be 
helpful.  Am I missing something?]

Scott

Date: Thu, 08 Apr 2004 08:05:27 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

At 11:42 AM 4/7/2004 +0100, Stephen Farrell wrote:

>>Sure.  Given mean rate of segment loss (from historical statistics, or 
>>from operational predictions from Somewhere Else) and number of data 
>>segments in block (computed from block size and maximum data segment 
>>size), compute expected number of segments lost in the initial 
>>transmission of this block.  Add 1; the result is B, the number of data 
>>segments that you would like to include block ID, to minimize the chance 
>>of block ID not being received in any data segment on initial 
>>transmission.  Divide the number of data segments in the block by B, 
>>yielding N; during initial transmission insert block ID into the first 
>>data segment of the block and into every Nth subsequent data segment.
>>I don't claim that this is the world's cleverest algorithm for this 
>>purpose, but it's the sort of thing I can imagine a mission asking for.
>>Anyway, I think it's an existence proof that there is no magic involved.
>
>Yes it is. Thanks. (Not that I like it mind, but it is an existence
>proof!)
>
>Would be it fair to ask to include that as an example in the spec and
>also to warn that implementations which handle block IDs SHOULD NOT
>expose the LTP fragmentation of higher layer blocks to the higher layer?
>The spec might also note that this isn't really useful below something
>like bundling as you said earlier.

That would certainly be fair, Stephen.  However, having stoutly defended 
this feature of LTP for several days I now find myself losing enthusiasm 
for it.  It really isn't useful under bundling, which is the main client 
service that LTP is designed for, and the only other upper-layer services 
on the horizon would be the ones you're contemplating, which very clearly 
don't need it.  Removing it would simplify the protocol in several ways 
(e.g., we would no longer need segment type code 10).  Maybe this is a CFDP 
design feature that LTP shouldn't bother to inherit, because it ends up 
being too low in the stack to do any good.

I can probably be talked back out of this, but I'm now starting to think we 
should jettison block ID from LTP altogether.  If there are any LTP block 
ID fans out there, please speak up.

Scott 

From: "Keith Scott" <[email-masked]>
To: "'Melissa Ho'" <[email-masked]>, <[email-masked]>
Subject: RE: [dtn-interest] fragmentation and erasure coding in Bundling
Date: Thu, 8 Apr 2004 10:17:28 -0400
Organization: The MITRE Corporation
Sender: [email-masked]

A la IP fragmentation, I think you're interpreting it correctly.

		--keith 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Melissa Ho
>Sent: Wednesday, April 07, 2004 2:05 PM
>To: [email-masked]
>Subject: Re: [dtn-interest] fragmentation and erasure coding 
>in Bundling
>
>> >I would prefer keeping it to single level fragmentation, which is in
>> >keeping with the protocol spec.
>> 
>> I think the protocol spec says you can fragment a bundle, 
>not that you can 
>> only fragment a non-fragmentary bundle.  If so, the spec 
>already supports 
>> multi-level fragmentation.
>
>That's not what I meant.  You can fragment a fragmented 
>bundle, but the 
>resulting bundles are all single level fragments - they are 
>not seen as 
>fragments of fragments.  Here's the text from the spec - let 
>me know if I've 
>misread it:
>
>-- begin snippet
>4.3.1 Bundle Fragmentation
>... (skip to second point) ...
>* In addition to the original headers, each bundle fragment 
>MUST containa 
>fragment header identifying the fragmentary payload's position 
>within the 
>original payload and the length of the original (unfragmented) 
>bundle's 
>payload. Note that there is only one 'level' of fragmentation 
>(as in IP 
>fragmentation).
>-- end snippet
>
>> >Oh so "bindling" is actually a word and not a misspelling.  
>I would say
>> >this is not a profound architectural change - just a gray 
>area that hadn't
>> >been implemented and now needs clarification.
>> 
>> Except that I think it's currently not a gray area at all: 
>you take custody 
>> of bundles, period.  If the bundle happens to be a 
>fragmentary bundle, 
>> well, okay, you're taking custody of a fragmentary bundle; 
>the previous 
>> custodian needs to recognize this by replicating the 
>fragmentation after 
>> the fact (if necessary) and releasing custody of the 
>fragment identified in 
>> the custody ack.
>
>This is where I think the spec needed the section on what 
>happens when you 
>receive custody ACKs, bundle receipts, etc.  In its absence, 
>it made sense to 
>me that the previous custodian holds on to the entire bundle until its 
>constituent fragments have all been ACKed individually. As far 
>as I can tell, 
>you believe that when the bundle agent decides to fragment a 
>bundle, it 
>replaces its copy of the bundle with the fragments, and then 
>manages it from 
>there. 
>
>I can see there's a valid argument for that point of view, and 
>it makes sense, 
>even if it violates my instinct that distributed custody is 
>just a bad idea.  
>
>Here's a question: Where in the protocol should the decision 
>of where to 
>fragment the bundle to occur? Based on our conversations, it is:
>a) In the convergence layer - all fragmentation is reactive  --or--
>b) In the convergence layer - the CL should handle the 
>breaking of bundles 
>across multiple upcoming contacts, not the bundle routing
>c) In Step 5. Forward the bundle
>
>If the answer is (a) or (b), then the argument is more 
>fundamental. But if it 
>is (c), I suggest the following changes to the protocol spec:
>* Change Step 4c to read "hop(s)" instead of "hop"
>* Add a point to Step 4c as follows:
>  o If the next hop's upcoming contact is not long enough to 
>send the entire 
>bundle, then the agent MAY choose a set of next hops over 
>which to send the 
>bundle as fragments. The agent can choose a set of contacts 
>over the same 
>next hoop, or a set of contacts over different hops.
>* Introduce a Step 4d as follows:
>Step 4d: Fragment the bundle if necessary.
>o If the bundle is going out on multiple contacts, then it 
>must be fragmented 
>prior to being forwarded. The bundle fragments MUST adhere to the 
>specification defined in section 4.3.1
>o If the bundle agent has custody of this bundle, it MUST 
>assume custody of 
>the fragments as in Step 4b, remove the original bundle from 
>its persistent 
>storage, and remove the retransmission timer for the original 
>bundle. It does 
>NOT need to send another acknowledgement to the previous custodian.
>(actually.... rather than referring to 4b, you might just 
>rewrite relevant 
>portions, to explain how to split custody)
>* Change Step 5 to read "bundle(s)" instead of "bundle" and 
>"adapter(s)" 
>instead of "adapter"
>
>> I believe that too.  I just don't think that means that 
>erasure coding has 
>> to be built into the bundling protocol.
>
>Certainly the bundling protocol will not die just because it 
>doesn't have 
>erasure coding. At the same time, I think erasure coding adds valuable 
>functionality to the bundling protocol. It's no more complex 
>than custodial 
>transfer.
>
>> It doesn't bother me that bundling might end up quite small 
>and simple if 
>> we leave DF out of it; I like small and simple, it often 
>means "working".
>
>Erasure coding is smaller and simpler than you probably 
>realize.  The open 
>source code I have less than 2000 lines, and can easily be 
>smaller if I 
>reduce it to just the encoder and decoder.
>
>Yes, it introduces some angles to DTN that may not be 
>applicable in all 
>situations. However, given that this is an architecture 
>targeted towards 
>*unreliable* networks, I think we should include mechanisms 
>that address 
>reliability. I do agree in that these mechanisms should be 
>small and simple 
>solutions.
>
>> 
>> We certainly don't want bundling to be so generalized that 
>it doesn't do 
>> anything useful.  But if bundling does nothing but deferred 
>transmission, 
>> store-and-forward, trans-regional routing, and options for 
>inter-node 
>> suspicion, custody transfer, congestion control, resilient delivery, 
>> payload security, and some priority and reporting features, 
>then I think it 
>> is doing quite a lot of useful stuff.  Let's do some other 
>useful stuff 
>> somewhere else.
>exactly. erasure coding is part of doing resilient delivery.
>
>Melissa
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Thu, 08 Apr 2004 12:19:58 +0100
From: Stephen Farrell <[email-masked]>
To: Howard Weiss <[email-masked]>
Cc: Kevin Fall <[email-masked]>, Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] fragmentation and erasure coding in Bundling  + q on ecc
Sender: [email-masked]

> I do remember reading about some of the shortfalls of the technology - 
> if memory serves me correctly, the server generates all the private keys 
> so the TTP doesn't go away (and can act as a key escrow agent, which can 
> be both good or bad depending on your environment), and because the 
> sender of a message can be anonymous, identity is refutable.

Yes. Put another way, IBC inherently involves key escrow, and that's
true for all IBC schemes, not just Boneh's (which is afaik by far
the most elegant to date).

However, I do think there are DTN applications of IBC, especially
if you buy into the region concept a lot - seems like crypto
applied to bundles which are aimed at a region could well use IBC
(where the "identity" being used to encrypt is effectively the
destination region) if there were some prior inter-regional
agreements in place. That makes regions more like administrative
boundaries though, rather than the current region model which I
think of as more geographical.

Kevin - how were you thinking of applying IBC?

Stephen.

Date: Wed, 7 Apr 2004 20:09:12 -0700 (PDT)
From: Ike nwaneri <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] URGENT NEED FROM A STUDENT
Sender: [email-masked]

--0-1350576983-1081393752=:14283
Content-Type: text/plain; charset=us-ascii

I need to know whether there is any data out there or any website i could find some data -- the listed meeting times of people in an area or certain place or the times listed that mobile devices (PDAs, cellphones, etc)  come within range of another.  I want this actual data to use for an experiment.  Please is there anyone that knows where i could find such data?  It is very urgent....
 
ike

---------------------------------
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter today
--0-1350576983-1081393752=:14283
Content-Type: text/html; charset=us-ascii

<DIV>I need to know whether there is any data out there or any website i could find some data -- the listed meeting times of people in an area or certain place or the times listed that mobile devices (PDAs, cellphones, etc)&nbsp; come within range of another.&nbsp; I want this actual data to use for an experiment.&nbsp; Please is there anyone that knows where i could find such data?&nbsp; It is very urgent....</DIV>
<DIV>&nbsp;</DIV>
<DIV>ike</DIV><p><hr size=1><font face=arial size=-1>Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/evt=23609/*http://promotions.yahoo.com/design_giveaway/static/index2.html">Yahoo! Small Business $15K Web Design Giveaway</a> - Enter today
--0-1350576983-1081393752=:14283--

From: Melissa Ho <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] fragmentation and erasure coding in Bundling
Date: Wed, 7 Apr 2004 18:05:29 +0000
Sender: [email-masked]

> >I would prefer keeping it to single level fragmentation, which is in
> >keeping with the protocol spec.
> 
> I think the protocol spec says you can fragment a bundle, not that you can 
> only fragment a non-fragmentary bundle.  If so, the spec already supports 
> multi-level fragmentation.

That's not what I meant.  You can fragment a fragmented bundle, but the 
resulting bundles are all single level fragments - they are not seen as 
fragments of fragments.  Here's the text from the spec - let me know if I've 
misread it:

-- begin snippet
4.3.1 Bundle Fragmentation
... (skip to second point) ...
* In addition to the original headers, each bundle fragment MUST containa 
fragment header identifying the fragmentary payload's position within the 
original payload and the length of the original (unfragmented) bundle's 
payload. Note that there is only one 'level' of fragmentation (as in IP 
fragmentation).
-- end snippet

> >Oh so "bindling" is actually a word and not a misspelling.  I would say
> >this is not a profound architectural change - just a gray area that hadn't
> >been implemented and now needs clarification.
> 
> Except that I think it's currently not a gray area at all: you take custody 
> of bundles, period.  If the bundle happens to be a fragmentary bundle, 
> well, okay, you're taking custody of a fragmentary bundle; the previous 
> custodian needs to recognize this by replicating the fragmentation after 
> the fact (if necessary) and releasing custody of the fragment identified in 
> the custody ack.

This is where I think the spec needed the section on what happens when you 
receive custody ACKs, bundle receipts, etc.  In its absence, it made sense to 
me that the previous custodian holds on to the entire bundle until its 
constituent fragments have all been ACKed individually. As far as I can tell, 
you believe that when the bundle agent decides to fragment a bundle, it 
replaces its copy of the bundle with the fragments, and then manages it from 
there. 

I can see there's a valid argument for that point of view, and it makes sense, 
even if it violates my instinct that distributed custody is just a bad idea.  

Here's a question: Where in the protocol should the decision of where to 
fragment the bundle to occur? Based on our conversations, it is:
a) In the convergence layer - all fragmentation is reactive  --or--
b) In the convergence layer - the CL should handle the breaking of bundles 
across multiple upcoming contacts, not the bundle routing
c) In Step 5. Forward the bundle

If the answer is (a) or (b), then the argument is more fundamental. But if it 
is (c), I suggest the following changes to the protocol spec:
* Change Step 4c to read "hop(s)" instead of "hop"
* Add a point to Step 4c as follows:
  o If the next hop's upcoming contact is not long enough to send the entire 
bundle, then the agent MAY choose a set of next hops over which to send the 
bundle as fragments. The agent can choose a set of contacts over the same 
next hoop, or a set of contacts over different hops.
* Introduce a Step 4d as follows:
Step 4d: Fragment the bundle if necessary.
o If the bundle is going out on multiple contacts, then it must be fragmented 
prior to being forwarded. The bundle fragments MUST adhere to the 
specification defined in section 4.3.1
o If the bundle agent has custody of this bundle, it MUST assume custody of 
the fragments as in Step 4b, remove the original bundle from its persistent 
storage, and remove the retransmission timer for the original bundle. It does 
NOT need to send another acknowledgement to the previous custodian.
(actually.... rather than referring to 4b, you might just rewrite relevant 
portions, to explain how to split custody)
* Change Step 5 to read "bundle(s)" instead of "bundle" and "adapter(s)" 
instead of "adapter"

> I believe that too.  I just don't think that means that erasure coding has 
> to be built into the bundling protocol.

Certainly the bundling protocol will not die just because it doesn't have 
erasure coding. At the same time, I think erasure coding adds valuable 
functionality to the bundling protocol. It's no more complex than custodial 
transfer.

> It doesn't bother me that bundling might end up quite small and simple if 
> we leave DF out of it; I like small and simple, it often means "working".

Erasure coding is smaller and simpler than you probably realize.  The open 
source code I have less than 2000 lines, and can easily be smaller if I 
reduce it to just the encoder and decoder.

Yes, it introduces some angles to DTN that may not be applicable in all 
situations. However, given that this is an architecture targeted towards 
*unreliable* networks, I think we should include mechanisms that address 
reliability. I do agree in that these mechanisms should be small and simple 
solutions.

> 
> We certainly don't want bundling to be so generalized that it doesn't do 
> anything useful.  But if bundling does nothing but deferred transmission, 
> store-and-forward, trans-regional routing, and options for inter-node 
> suspicion, custody transfer, congestion control, resilient delivery, 
> payload security, and some priority and reporting features, then I think it 
> is doing quite a lot of useful stuff.  Let's do some other useful stuff 
> somewhere else.
exactly. erasure coding is part of doing resilient delivery.

Melissa

Date: Wed, 07 Apr 2004 12:46:50 -0400
From: Howard Weiss <[email-masked]>
To: Stephen Farrell <[email-masked]>
CC: Kevin Fall <[email-masked]>, Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] fragmentation and erasure coding in Bundling  + q on ecc
Sender: [email-masked]

Kevin,

A couple of things - see inline.

Stephen Farrell wrote:

>
> Kevin,
>
> >>I can't think of a good
>
>>> counter example where the "base spec with lots of
>>> options + profiling" approach has worked nicely, but maybe
>>> there is one.
>>
>>
>> how about rtp?
>> I believe BGP has a somewhat related situation.
>> 802.11b has DCF and PCF plus optional encryption
>
>
> I'm not familiar enough with those to argue, but...
>
>> ssh has at least 3 commonly used distinct authentication algorithm 
>> options
>
>
> SSH started life as code that did one thing and is certainly
> not a counter example to the PKIX "lesson" I quoted. 

I agree - however I would not necessarily classify the use of different 
algorithms within SSH as "profiles" per se.  I typically think of 
profiles as standardized ways to use protocol - specifically which 
options to use and which options to not use.  An SSH profile, to me, 
might be the allowance of only SHA and not allowing the use of MD5 
rather than the fact that SSH has multiple algorithms available within 
its specification.

>
>
>> Could you expand on this a bit?  I've of recent been looking at the
>> "BH scheme" for Identity Based Crypto, which uses the Weil/Tate
>> pairing on elliptic curves.  But Boneh and Franklin now work for
>> "Voltage.com".  Do you know about the proprietariness of this
>> scheme?
>
>
> I haven't gotten into IBC really, so can't (and wouldn't anyway:-)
> say what IPR might apply. Elliptic curves have been around for
> much longer than IPR so that in itself isn't necessarily an
> indicator. I also recall Dan Boneh making presentations where
> he claimed his IBC scheme was different from the UK CESG one
> since, amongst other reasons, theirs was patented. But IANAL
> etc. - best is probably to ask Boneh if you need an answer.
>
> For ECC generally, the patents tend to be on speedy ways to
> implement (or generate good keys) and the company to look
> for as assignee is Certicom, who hold afaik most all the
> relevant IPR (just looked at their site for the 1st time
> in ages and they say they've 300 patents and filings - so
> I'm not reading up on that:-) I've no idea if Certicom have
> any filings related to IBC. Wouldn't be surprised either
> way.
>
> Stephen.
>
Like Stephen, I have not gotten deeply into IBC.  Nor do I know the 
status of any patents on the IP (although if Voltage is following the 
Certicom model, everything to do with the technology will be claimed!).  
I do remember reading about some of the shortfalls of the technology - 
if memory serves me correctly, the server generates all the private keys 
so the TTP doesn't go away (and can act as a key escrow agent, which can 
be both good or bad depending on your environment), and because the 
sender of a message can be anonymous, identity is refutable.

Howie

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

Date: Wed, 07 Apr 2004 16:45:53 +0100
From: Stephen Farrell <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] fragmentation and erasure coding in Bundling  + q on ecc
Sender: [email-masked]

Kevin,

 >>I can't think of a good
>>counter example where the "base spec with lots of
>>options + profiling" approach has worked nicely, but maybe
>>there is one.
> 
> how about rtp?
> I believe BGP has a somewhat related situation.
> 802.11b has DCF and PCF plus optional encryption

I'm not familiar enough with those to argue, but...

> ssh has at least 3 commonly used distinct authentication algorithm options

SSH started life as code that did one thing and is certainly
not a counter example to the PKIX "lesson" I quoted.

> Could you expand on this a bit?  I've of recent been looking at the
> "BH scheme" for Identity Based Crypto, which uses the Weil/Tate
> pairing on elliptic curves.  But Boneh and Franklin now work for
> "Voltage.com".  Do you know about the proprietariness of this
> scheme?

I haven't gotten into IBC really, so can't (and wouldn't anyway:-)
say what IPR might apply. Elliptic curves have been around for
much longer than IPR so that in itself isn't necessarily an
indicator. I also recall Dan Boneh making presentations where
he claimed his IBC scheme was different from the UK CESG one
since, amongst other reasons, theirs was patented. But IANAL
etc. - best is probably to ask Boneh if you need an answer.

For ECC generally, the patents tend to be on speedy ways to
implement (or generate good keys) and the company to look
for as assignee is Certicom, who hold afaik most all the
relevant IPR (just looked at their site for the 1st time
in ages and they say they've 300 patents and filings - so
I'm not reading up on that:-) I've no idea if Certicom have
any filings related to IBC. Wouldn't be surprised either
way.

Stephen.

To: Stephen Farrell <[email-masked]>
cc: Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] fragmentation and erasure coding in Bundling  + q on ecc
Date: Wed, 07 Apr 2004 08:23:50 -0700
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

>
> From:  Stephen Farrell <[email-masked]>
> To:    Scott Burleigh <[email-masked]>
> cc:    [email-masked]
> Subject: Re: [dtn-interest] fragmentation and erasure coding in Bundling
> Date:  Wed, 07 Apr 2004 12:17:50 BST
>
> 
> FWIW, I'd strongly support Scott's overall approach on
> this one!
> 
> As a datapoint: the IETF PKIX WG started life to make
> profiles of X.509...   ...in 1995, with the first RFCs in
> 1999... ...and its still going! I can't think of a good
> counter example where the "base spec with lots of
> options + profiling" approach has worked nicely, but maybe
> there is one.

how about rtp?
I believe BGP has a somewhat related situation.
802.11b has DCF and PCF plus optional encryption
ssh has at least 3 commonly used distinct authentication algorithm options

> 
> Also, (and I have to admit from a perspective of pretty much
> total ignorance of erasure coding), I find the mention of
> "proprietary" and "the open source version" to be quite scary,
> esp. if the suggestion is to allow such features into a base
> DTN spec.

yes, I understand that particular sensitivity.  This is not
sufficiently explored yet.

> It reminds me of elliptic curve cryptography (ECC).
> A nice technology, and the basic algorithms aren't patented,
> but most all of the best ways to implement ECC efficiently
> are encumbered. Turns me personally off including ECC even
> as a option in a base spec. (Having independent subsidiary
> specs which tell you how to use ECC if you want to, is just
> fine though.)

Could you expand on this a bit?  I've of recent been looking at the
"BH scheme" for Identity Based Crypto, which uses the Weil/Tate
pairing on elliptic curves.  But Boneh and Franklin now work for
"Voltage.com".  Do you know about the proprietariness of this
scheme?

- K

Date: Wed, 07 Apr 2004 10:21:07 -0400
From: Howard Weiss <[email-masked]>
To: Kevin Fall <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] fragmentation and erasure coding in Bundling
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------050801030705010700010704
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Go to the bottom......

Kevin Fall wrote:

>There has been some recent discussion regarding how to implement
>bundle fragmentation, what to do about custody transfer when
>fragments are used, and what happens if we consider using
>Digital Fountain (DF)-like codes in conjunction with fragmentation.
>[There is a set of online codes similar to DF functionality but which are not proprietary].
>Scott has nicely summarized and asked some provocative questions
>regarding this, below...
>
>  
>
>>From:  Scott Burleigh <[email-masked]>
>>Subject: erasure coding in Bundling
>>Date:  Tue, 06 Apr 2004 08:15:06 PDT
>>
>>One impression I got [...] was this: maybe we don't 
>>all agree that adding erasure coding as an alternative fragmentation 
>>mechanism within bundling itself (as opposed to an end-to-end system above 
>>bundling or a convergence-layer system underneath bundling) would 
>>necessarily have a huge impact on the DTN architecture and the Bundling 
>>protocol spec.  It's just one additional header, after all.
>>
>>To try to make my point that we are talking about a major, destabilizing 
>>change, I started writing down some of the questions I thought we would 
>>need to answer before issuing the next round of architecture and protocol 
>>spec drafts:
>>
>>When Bundling uses DF to fragment a bundle, issuing code blocks, are the 
>>code blocks issued in bundles, or are they issued in some other type of
>>protocol data unit?  If the latter, we've got a profound architectural change.
>>    
>>
>
>in bundles, I would think.  We may need to mark them specially (via a
>revision of frag header), but are otherwise semantically the same
>
>  
>
>>If the code blocks are issued in bundles, are these bundles treated the 
>>same way as all other bundles (except, obviously, for the procedures used 
>>to reconstitute original bundles from them), or are there now two different 
>>classes of bundles that are treated differently by bundle agents?  If the 
>>latter, we've got a profound architectural change that seriously 
>>complicates the protocol.
>>    
>>
>
>just re-constitution
>
>  
>
>>If bundles whose payloads are DF code blocks (rather than conventional 
>>fragments) are treated just like all other bundles, then they must be
>>subject to reactive fragmentation like all other bundles, right?
>>    
>>
>
>yes
>
>  
>
>>If so, 
>>each one has to be uniquely identifiable (to enable conventional
>>reassembly); what uniquely identifying bundle ID extension accomplishes 
>>this?  When a DF code block is reactively fragmented, what do those
>>fragments look like?  Is the key (etc.) stuff of the DF code block carried 
>>only in the first of those fragments?
>>    
>>
>
>the simplest version would be to do conventional reactive frag if this
>happens (which would entail creating new frag headers with the
>appropriate info in them as would be normal).  There is a "fancier idea" we've been kicking around about
>actually munging the contents of the codeblock into parts, but this
>is still sort of open.
>
>  
>
>>If DF can be used to fragment a bundle, and all bundles are treated the 
>>same, then DF can be used to fragment a conventional fragment, right?  And
>>in fact DF can also be used to fragment a bundle whose payload is a DF code 
>>block, right?
>>    
>>
>
>yup, if you really care to do that
>
>  
>
>>If the only type of protocol data unit we've got in Bundling is Bundles, 
>>then the only thing you can take custody of is a bundle, yes?  If not, 
>>we've got a profound architectural change: "partial custody transfer", the 
>>ancient "bindling" argument.
>>    
>>
>
>Well, I'm not exactly sure what the change is.  If we go
>with the approach that frags are bundles, then 'partial custody' equates
>with 'custody'.  Only the reassembly is a bit different.
>
>  
>
>>If an application requests custodial delivery of an application data unit, 
>>does that QoS propagate to all fragments of the resulting bundle?  If not, 
>>we're not treating all bundles the same; a profound (and complicating) 
>>architectural change.
>>    
>>
>
>I assume it propagages, requiring no other change.
>
>  
>
>>If custodial delivery propagates to all fragments of the original bundle to 
>>which it was applied, then custodial delivery propagates to fragmentary
>>bundles resulting from DF encoding -- and to the conventional and/or DF 
>>fragments into which those fragments might be divided.  Are custody 
>>transfer procedures the same for those fragments as for the original 
>>bundle?  If not, we're not treating all bundles the same; we have 
>>introduced additional complexity into the protocol.  If so, any custodial 
>>retransmission that applies to DF-based fragments is redundant.
>>    
>>
>
>That might change, which I see might be like this.  If you are using an error correcting
>code and you successfully custody xfer some threshold percentage of them to other
>custodians then you assume you have successfully moved custody along.  This
>is different, but I think would lead to little code complexity.  The difference amounts
>to whether you use one ACK or multiple ACKs in order to assume you have done
>your job.
>
>  
>
>>What about custody transfer for conventional fragments of DF fragments?  Do 
>>we bother to do it, since it's at cross-purposes with the DF encoding?  If 
>>not, we have introduced another little increment of complexity into the 
>>protocol.
>>    
>>
>
>It could be allowed.  It just doesn't necessarily seem to offer profound
>benefits.
>
>  
>
>>If an application requests some other QoS service for an application data 
>>unit, such as reception reporting, does that QoS propagate to all fragments 
>>of the resulting bundle?  If not, we've got a significant architectural chang
>>    
>>
>e.
>
>I'm not sure.  It may depend.  I am reminded about ICMP messages for
>fragments.  In that case, there are particular rules that apply to fragments,
>and I would be terribly surprised if we end up going in a similar direction.
>But I also don't think this should pose too much of a problem.  Indeed, my
>hunch is that frags would be treated as bundles generally, but in the
>particular e2e ack case we have available you would need the entire thing
>to be at the final dest (which is the case anyhow).
>
>  
>
>>If reception reporting propagates to all fragments of the original bundle 
>>to which it was applied, then reception reporting propagates to fragmentary 
>>bundles resulting from DF encoding -- and to the conventional and/or DF 
>>fragments into which those fragments might be divided.  This could result 
>>in some pretty baffling and useless reports being passed back to the source 
>>application.  If we don't do this, we're not treating all bundles the same; 
>>we have introduced additional complexity into the protocol.
>>    
>>
>
>why would it be baffling?  Also, recall that the reports don't need
>to be sent back to the source.  Although I'm not sure of this, if you
>frag an IP packet with a low ttl and the frags are, say, routed in different
>paths and they expire in-transit... I believe you get an ICMP indication for
>each... but I would have to check that.
>
>  
>
>>These are the only points I can think of off the top of my head, without 
>>any of the documents in front of me.  If we start down this path in 
>>earnest, of course, we will have to go through the spec and the 
>>architecture draft in detail to see what else must be addressed.
>>
>>All of which would obviously be worthwhile if erasure coding were a central 
>>and indispensable capability for delay-tolerant networking.  It is not.
>>
>>Certainly it will be extremely valuable in a number of environments, 
>>possibly a very large number: it's a great way to do multi-path routing, 
>>and it's a great way to do multicast.  But in 18 years of network systems 
>>development at JPL I have never seen an application that needed 
>>multicast.  I have seen maybe one application that could have used 
>>multi-path routing, to compensate for some deficiencies in network 
>>design.  You don't need multicast when there's only a single destination; 
>>you don't need multi-path when there's only a single path, or when any 
>>single path is sufficient to carry your message.  Applications with these 
>>characteristics will be with us for a long time.
>>
>>I do not doubt for an instant that multi-path and multicast are needed for 
>>military applications, especially mobile tactical applications; I don't 
>>doubt for an instant that the Internet needs multicast for information 
>>streaming, nor that it needs multi-path for mobile applications.  We 
>>certainly have got to support this stuff.
>>
>>What we don't need to do, though, is make it a cornerstone of 
>>delay-tolerant networking, any more than we need to make ephemerides-aware 
>>forwarding a cornerstone of delay-tolerant networking.  The additional 
>>complexity imposed by these devices is amply justified in the environments 
>>where they are needed, but not in the core of bundling that everybody has 
>>to work with.  Let's implement them in convergence layer adapters where 
>>they are required, rather than jam them down the throats of developers and 
>>users who do not want or need them.  Let's be modular.  Let's try to avoid 
>>making CFDP's mistakes all over again.
>>
>>Scott
>>
>>    
>>
>
>Well, hmm.  So this is the realm of opinion I guess.  I believe that
>there are two primary things dtn wishes to accomplish:  handle disconnection
>reasonably well, and handle interoperability across very heterogeneous
>networks.  To handle disconnection we have the concepts of contacts
>and an interesting routing problem becomes to "fill" them.  In a broad
>range of cases there are multiple paths available (because of the "new ability"
>to handle heterogeneous devices [think: 'if I have any connection possible I can
>make use of it with DTN']) and in some of those simultaneous use will be
>desirable.  Fragmentation is for two things:  1> what to do to large messages
>so you can send them over multiple paths, perhaps simultaneously, and 2> what
>to do with a large message while, during a transfer at a link, you encouter
>an interruption but you still want to make use of that data that did arrive.
>#2 is the 'reactive fragmentation' concept, and it is a performance optimization.
>If the "main routing" is functioning properly and there are no unexpected interruptions
>you should never see it happening.
>
>I cannot address multicast with as much clarity.  Lots of networking experience
>has shown us that reliable multicasting at large scale is difficult.  However,
>for smaller scale its not so difficult.  It is
>certainly more complex.  Should DTN support 'small-scale' multicast?
>I'm not completely sure, but if the answer is 'no' then we have to do it on top.
>That would amount to a reliable multicast overlay on top of dtn, which is an
>overlay itself [gag], so my inclination would be to embrace multicast at least
>at some point.  However, in order to maintain progress with our
>current direction, I'm willing to forego the mcast part while we get
>fragmentation working properly.  [of course, there's also security to do too :<>].
>
>  
>
Security in concert with fragmentation is a MAJOR headache.  The 
question/problem is where the security mechanisms are applied versus 
where/when the fragmentation takes place.  For example, if 
confidentiality is required (aka, encryption) and the bundle payload is 
encrypted and the fragmented, each and every fragement would have to be 
received at the destination before the bundle could be decrypted.  On 
the other hand, if fragmentation took place first, each bundle fragement 
becomes an atomic entity and can be treated independent of all other 
bundles from a decryption standpoint.  With IPSec over the Internet, we 
have the situation where encrypted data is fragmented and all the 
fragments must be reassembled at the destination before decryption can 
take place.  However, the Internet does not lose or mangle too many 
packets over land-line connections!  RF connections make it more of a 
problem unless you seriously apply coding to the link.

Multicast on a non-broadcast network is a problem (which is why so many 
of us can't receive multicast since our ISPs don't route it). Multicast 
in concert with security is even worse -it still has a scaling problem.  
Work is underway (several of my colleages a few offices down from mine 
have been working on group key management for multicast for several 
years), but there is still a scaling problem.  Cryptographically keying 
thousands, or hundreds of thousands of multicast group members is a 
problem.  Re-keying them to cryptographically isolate a 'bad-guy' from 
the midst of thousands is a really hard problem. 

Howie

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

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Go to the bottom......<br>
<br>
Kevin Fall wrote:<br>
<blockquote type="cite"
 cite="[email-masked]">
  <pre wrap="">There has been some recent discussion regarding how to implement
bundle fragmentation, what to do about custody transfer when
fragments are used, and what happens if we consider using
Digital Fountain (DF)-like codes in conjunction with fragmentation.
[There is a set of online codes similar to DF functionality but which are not proprietary].
Scott has nicely summarized and asked some provocative questions
regarding this, below...

  </pre>
  <blockquote type="cite">
    <pre wrap="">From:  Scott Burleigh <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Subject: erasure coding in Bundling
Date:  Tue, 06 Apr 2004 08:15:06 PDT

One impression I got [...] was this: maybe we don't 
all agree that adding erasure coding as an alternative fragmentation 
mechanism within bundling itself (as opposed to an end-to-end system above 
bundling or a convergence-layer system underneath bundling) would 
necessarily have a huge impact on the DTN architecture and the Bundling 
protocol spec.  It's just one additional header, after all.

To try to make my point that we are talking about a major, destabilizing 
change, I started writing down some of the questions I thought we would 
need to answer before issuing the next round of architecture and protocol 
spec drafts:

When Bundling uses DF to fragment a bundle, issuing code blocks, are the 
code blocks issued in bundles, or are they issued in some other type of
protocol data unit?  If the latter, we've got a profound architectural change.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
in bundles, I would think.  We may need to mark them specially (via a
revision of frag header), but are otherwise semantically the same

  </pre>
  <blockquote type="cite">
    <pre wrap="">If the code blocks are issued in bundles, are these bundles treated the 
same way as all other bundles (except, obviously, for the procedures used 
to reconstitute original bundles from them), or are there now two different 
classes of bundles that are treated differently by bundle agents?  If the 
latter, we've got a profound architectural change that seriously 
complicates the protocol.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
just re-constitution

  </pre>
  <blockquote type="cite">
    <pre wrap="">If bundles whose payloads are DF code blocks (rather than conventional 
fragments) are treated just like all other bundles, then they must be
subject to reactive fragmentation like all other bundles, right?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
yes

  </pre>
  <blockquote type="cite">
    <pre wrap="">If so, 
each one has to be uniquely identifiable (to enable conventional
reassembly); what uniquely identifying bundle ID extension accomplishes 
this?  When a DF code block is reactively fragmented, what do those
fragments look like?  Is the key (etc.) stuff of the DF code block carried 
only in the first of those fragments?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
the simplest version would be to do conventional reactive frag if this
happens (which would entail creating new frag headers with the
appropriate info in them as would be normal).  There is a "fancier idea" we've been kicking around about
actually munging the contents of the codeblock into parts, but this
is still sort of open.

  </pre>
  <blockquote type="cite">
    <pre wrap="">If DF can be used to fragment a bundle, and all bundles are treated the 
same, then DF can be used to fragment a conventional fragment, right?  And
in fact DF can also be used to fragment a bundle whose payload is a DF code 
block, right?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
yup, if you really care to do that

  </pre>
  <blockquote type="cite">
    <pre wrap="">If the only type of protocol data unit we've got in Bundling is Bundles, 
then the only thing you can take custody of is a bundle, yes?  If not, 
we've got a profound architectural change: "partial custody transfer", the 
ancient "bindling" argument.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Well, I'm not exactly sure what the change is.  If we go
with the approach that frags are bundles, then 'partial custody' equates
with 'custody'.  Only the reassembly is a bit different.

  </pre>
  <blockquote type="cite">
    <pre wrap="">If an application requests custodial delivery of an application data unit, 
does that QoS propagate to all fragments of the resulting bundle?  If not, 
we're not treating all bundles the same; a profound (and complicating) 
architectural change.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I assume it propagages, requiring no other change.

  </pre>
  <blockquote type="cite">
    <pre wrap="">If custodial delivery propagates to all fragments of the original bundle to 
which it was applied, then custodial delivery propagates to fragmentary
bundles resulting from DF encoding -- and to the conventional and/or DF 
fragments into which those fragments might be divided.  Are custody 
transfer procedures the same for those fragments as for the original 
bundle?  If not, we're not treating all bundles the same; we have 
introduced additional complexity into the protocol.  If so, any custodial 
retransmission that applies to DF-based fragments is redundant.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
That might change, which I see might be like this.  If you are using an error correcting
code and you successfully custody xfer some threshold percentage of them to other
custodians then you assume you have successfully moved custody along.  This
is different, but I think would lead to little code complexity.  The difference amounts
to whether you use one ACK or multiple ACKs in order to assume you have done
your job.

  </pre>
  <blockquote type="cite">
    <pre wrap="">What about custody transfer for conventional fragments of DF fragments?  Do 
we bother to do it, since it's at cross-purposes with the DF encoding?  If 
not, we have introduced another little increment of complexity into the 
protocol.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
It could be allowed.  It just doesn't necessarily seem to offer profound
benefits.

  </pre>
  <blockquote type="cite">
    <pre wrap="">If an application requests some other QoS service for an application data 
unit, such as reception reporting, does that QoS propagate to all fragments 
of the resulting bundle?  If not, we've got a significant architectural chang
    </pre>
  </blockquote>
  <pre wrap=""><!---->e.

I'm not sure.  It may depend.  I am reminded about ICMP messages for
fragments.  In that case, there are particular rules that apply to fragments,
and I would be terribly surprised if we end up going in a similar direction.
But I also don't think this should pose too much of a problem.  Indeed, my
hunch is that frags would be treated as bundles generally, but in the
particular e2e ack case we have available you would need the entire thing
to be at the final dest (which is the case anyhow).

  </pre>
  <blockquote type="cite">
    <pre wrap="">If reception reporting propagates to all fragments of the original bundle 
to which it was applied, then reception reporting propagates to fragmentary 
bundles resulting from DF encoding -- and to the conventional and/or DF 
fragments into which those fragments might be divided.  This could result 
in some pretty baffling and useless reports being passed back to the source 
application.  If we don't do this, we're not treating all bundles the same; 
we have introduced additional complexity into the protocol.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
why would it be baffling?  Also, recall that the reports don't need
to be sent back to the source.  Although I'm not sure of this, if you
frag an IP packet with a low ttl and the frags are, say, routed in different
paths and they expire in-transit... I believe you get an ICMP indication for
each... but I would have to check that.

  </pre>
  <blockquote type="cite">
    <pre wrap="">These are the only points I can think of off the top of my head, without 
any of the documents in front of me.  If we start down this path in 
earnest, of course, we will have to go through the spec and the 
architecture draft in detail to see what else must be addressed.

All of which would obviously be worthwhile if erasure coding were a central 
and indispensable capability for delay-tolerant networking.  It is not.

Certainly it will be extremely valuable in a number of environments, 
possibly a very large number: it's a great way to do multi-path routing, 
and it's a great way to do multicast.  But in 18 years of network systems 
development at JPL I have never seen an application that needed 
multicast.  I have seen maybe one application that could have used 
multi-path routing, to compensate for some deficiencies in network 
design.  You don't need multicast when there's only a single destination; 
you don't need multi-path when there's only a single path, or when any 
single path is sufficient to carry your message.  Applications with these 
characteristics will be with us for a long time.

I do not doubt for an instant that multi-path and multicast are needed for 
military applications, especially mobile tactical applications; I don't 
doubt for an instant that the Internet needs multicast for information 
streaming, nor that it needs multi-path for mobile applications.  We 
certainly have got to support this stuff.

What we don't need to do, though, is make it a cornerstone of 
delay-tolerant networking, any more than we need to make ephemerides-aware 
forwarding a cornerstone of delay-tolerant networking.  The additional 
complexity imposed by these devices is amply justified in the environments 
where they are needed, but not in the core of bundling that everybody has 
to work with.  Let's implement them in convergence layer adapters where 
they are required, rather than jam them down the throats of developers and 
users who do not want or need them.  Let's be modular.  Let's try to avoid 
making CFDP's mistakes all over again.

Scott

    </pre>
  </blockquote>
  <pre wrap=""><!---->
Well, hmm.  So this is the realm of opinion I guess.  I believe that
there are two primary things dtn wishes to accomplish:  handle disconnection
reasonably well, and handle interoperability across very heterogeneous
networks.  To handle disconnection we have the concepts of contacts
and an interesting routing problem becomes to "fill" them.  In a broad
range of cases there are multiple paths available (because of the "new ability"
to handle heterogeneous devices [think: 'if I have any connection possible I can
make use of it with DTN']) and in some of those simultaneous use will be
desirable.  Fragmentation is for two things:  1&gt; what to do to large messages
so you can send them over multiple paths, perhaps simultaneously, and 2&gt; what
to do with a large message while, during a transfer at a link, you encouter
an interruption but you still want to make use of that data that did arrive.
#2 is the 'reactive fragmentation' concept, and it is a performance optimization.
If the "main routing" is functioning properly and there are no unexpected interruptions
you should never see it happening.

I cannot address multicast with as much clarity.  Lots of networking experience
has shown us that reliable multicasting at large scale is difficult.  However,
for smaller scale its not so difficult.  It is
certainly more complex.  Should DTN support 'small-scale' multicast?
I'm not completely sure, but if the answer is 'no' then we have to do it on top.
That would amount to a reliable multicast overlay on top of dtn, which is an
overlay itself [gag], so my inclination would be to embrace multicast at least
at some point.  However, in order to maintain progress with our
current direction, I'm willing to forego the mcast part while we get
fragmentation working properly.  [of course, there's also security to do too :&lt;&gt;].

  </pre>
</blockquote>
Security in concert with fragmentation is a MAJOR headache.&nbsp; The
question/problem is where the security mechanisms are applied versus
where/when the fragmentation takes place.&nbsp; For example, if
confidentiality is required (aka, encryption) and the bundle payload is
encrypted and the fragmented, each and every fragement would have to be
received at the destination before the bundle could be decrypted.&nbsp; On
the other hand, if fragmentation took place first, each bundle
fragement becomes an atomic entity and can be treated independent of
all other bundles from a decryption standpoint.&nbsp; With IPSec over the
Internet, we have the situation where encrypted data is fragmented and
all the fragments must be reassembled at the destination before
decryption can take place.&nbsp; However, the Internet does not lose or
mangle too many packets over land-line connections!&nbsp; RF connections
make it more of a problem unless you seriously apply coding to the link.<br>
<br>
Multicast on a non-broadcast network is a problem (which is why so many
of us can't receive multicast since our ISPs don't route it). Multicast
in concert with security is even worse -it still has a scaling
problem.&nbsp; Work is underway (several of my colleages a few offices down
from mine have been working on group key management for multicast for
several years), but there is still a scaling problem.&nbsp;
Cryptographically keying thousands, or hundreds of thousands of
multicast group members is a problem.&nbsp; Re-keying them to
cryptographically isolate a 'bad-guy' from the midst of thousands is a
really hard problem.&nbsp; <br>
<br>
Howie<br>
<pre class="moz-signature" cols="72">-- 
Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)

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

--------------050801030705010700010704--

Date: Wed, 07 Apr 2004 12:17:50 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] fragmentation and erasure coding in Bundling
Sender: [email-masked]

FWIW, I'd strongly support Scott's overall approach on
this one!

As a datapoint: the IETF PKIX WG started life to make
profiles of X.509...   ...in 1995, with the first RFCs in
1999... ...and its still going! I can't think of a good
counter example where the "base spec with lots of
options + profiling" approach has worked nicely, but maybe
there is one.

Also, (and I have to admit from a perspective of pretty much
total ignorance of erasure coding), I find the mention of
"proprietary" and "the open source version" to be quite scary,
esp. if the suggestion is to allow such features into a base
DTN spec.  It reminds me of elliptic curve cryptography (ECC).
A nice technology, and the basic algorithms aren't patented,
but most all of the best ways to implement ECC efficiently
are encumbered. Turns me personally off including ECC even
as a option in a base spec. (Having independent subsidiary
specs which tell you how to use ECC if you want to, is just
fine though.)

Stephen.

Scott Burleigh wrote:
> At 06:07 PM 4/6/2004 -0400, Robert C. Durst wrote:
> 
>> >
>> >We DO have to write a single, unambiguous, comprehensive
>> >specification for
>> >the Bundling protocol, and every single compliant
>> >implementation of that
>> >protocol has got to implement all of it.  That is what
>> >protocol design is
>> >all about.
>>
>> Scott, I believe that this is a central part of the issue at hand.
>>
>> While I agree with the first part of your statement, I personally do NOT
>> believe that "every single compliant implementation of [bundling] has to
>> implement all of [the protocol specification]."  I believe that optional
>> capability is perfectly valid, has great precedent, and an approach
>> specifying "profiles" of the protocol for particular Delay Tolerant 
>> Networks
>> was what we had in mind when we broadened our scope from IPN to DTN.  I
>> believe that interoperability within profiles is an absolute 
>> necessity, but
>> across profiles is an implementation and marketing decision.
> 
> 
> Okay, a good point.
> 
> I think we agree that Bundling is a single protocol for which we must 
> have a single, unambiguous, comprehensive specification, but that this 
> specification might include procedures that are optional (meaning there 
> can be statements like "when X occurs, procedure Y MAY be performed -- 
> and if Y is performed it must be done in the following way").
> 
> If by a "profile" we mean not just an ops concept or deployment scenario 
> but instead some formal, comprehensive list of specific optional 
> procedures in the spec that MUST be performed by any implementation that 
> is to be considered compliant with that profile, then I agree that a 
> profile-based approach is valid and has plenty of precedent.
> 
> Judging from my experience with defining CFDP's "service classes" (same 
> idea), I think we would be opening ourselves up to a world of pain in 
> taking this approach.  It is hard enough to make sure that all cases are 
> addressed in a protocol design where everything is fixed; it is much 
> harder to assure the same level of coverage for multiple profiles, 
> making sure that no procedure that is mandatory in one profile is 
> dependent on any other procedure that is optional in that profile.
> 
> I think developing a spec in this way will either take a lot longer or 
> contain a lot more errors, or both, and the resulting document will be 
> significantly larger, more challenging to read, and more daunting to 
> implement from.  I really think we would be much better off partitioning 
> the DTN architectural problem into (a) a relatively small, simple 
> bundling specification and (b - z) some number of likewise relatively 
> small, simple convergence layer adapter specifications suited to various 
> types of environmental region.
> 
> It is not my intent to be obstructionist or Luddite here, I swear it 
> isn't.  I just want us all to succeed.  In my experience, big projects 
> fail; big systems don't work; big documents are unreadable, or at least 
> unread.  What works is the gradual accretion of a lot of small things, 
> each done well, that make up successful Big Things when you hook them 
> together.  Let's do a little bit, and get that right, and then do some 
> more.
> 
> Scott
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Wed, 07 Apr 2004 11:56:55 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] more ltp comments
Sender: [email-masked]

>> PS: Meanwhile, I've just noticed that each and every offset and length
>> field in an RS is an SDNV, and hence has its own length field 
>> requiring an additional byte for each, (assuming offsets & lengths would
>> be expected to be >127). So I think that the encoding of RS segments
>> isn't actually that parsimonious, which further argues for the
>> additional byte required to distinguish complete vs. truncated RS
>> segments. (As an aside, you could define a new type "SDNV-16" which
>> works like an SDNV but where the MSB being clear means that the
>> remainder of the 2-byte-fixed-size field is a value, and where the
>> MSB being set means that its handled like a current SDNV. You could
>> also have an SDNV-32, etc. and then depending on the likely values,
>> using those types can save you some bytes in RS segments and maybe
>> elsewhere. Not sure if that'd be worthwhile, was it considered
>> already?)
 >
> No, it wasn't, and I think it's a terrific idea.

Yeah, I think I like it too! Thinking further what I think
I'd do is the following:

Define a new bit in the control byte which determines whether
this segment is using SDNV-8 (unsigned version, otherwise as
in current draft) or else SDNV-16 (as above). All SDNV fields
in that segment are then encoded accordingly. There is no mixing
of SDNV-8 and SDNV-16 in a single segment. Then the receiver
has to be able to handle either, but that's no big deal. The
transmitter can choose which to send at its discretion. In my
code I'd probably take the dumb approach and encode both ways
and then just send the shorter buffer - I'd give that as an
example in the spec too.

Cleverer code might be able to do this with less CPU but the
above ie enough for me.

Given that a lot of SDNV fields represent lengths (bounds,
offsets, lengths) and blocks are probably of the order of ~1kb,
(~10bits for a length) then this should save a good bit over
the entire segment, since we save 33% on encoding such values.

On reflection, I also think there's no need to have more than
two SDNV's (-8 and -16), since a) there probably aren't that many
values in the [2^16,2^31) range that LTP is handling, b) we'd
need more than one header bit to flag its use, c) with more
variations the case for mixing the different types in a single
segment might seem more compelling, but that adds code
complexity, d) SDNV-16 can save 33% for a value compared to
SDNV-8, but SDNV-32 saves much less if used everywhere
(there'll definitely be values in the [0,2^15] range in
all segments), and, e) some other reason someone else can
provide:-)

Stephen.

PS: Now can I have my "number of offset/length" pairs byte in
the RS? :-)

Date: Wed, 07 Apr 2004 11:42:28 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

> Sure.  Given mean rate of segment loss (from historical statistics, or 
> from operational predictions from Somewhere Else) and number of data 
> segments in block (computed from block size and maximum data segment 
> size), compute expected number of segments lost in the initial 
> transmission of this block.  Add 1; the result is B, the number of data 
> segments that you would like to include block ID, to minimize the chance 
> of block ID not being received in any data segment on initial 
> transmission.  Divide the number of data segments in the block by B, 
> yielding N; during initial transmission insert block ID into the first 
> data segment of the block and into every Nth subsequent data segment.
> 
> I don't claim that this is the world's cleverest algorithm for this 
> purpose, but it's the sort of thing I can imagine a mission asking for.  
> Anyway, I think it's an existence proof that there is no magic involved.

Yes it is. Thanks. (Not that I like it mind, but it is an existence
proof!)

Would be it fair to ask to include that as an example in the spec and
also to warn that implementations which handle block IDs SHOULD NOT
expose the LTP fragmentation of higher layer blocks to the higher layer?
The spec might also note that this isn't really useful below something
like bundling as you said earlier.

Stephen.

Date: Tue, 06 Apr 2004 16:36:17 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] fragmentation and erasure coding in Bundling
Sender: [email-masked]

At 06:37 PM 4/6/2004 -0400, Melissa Ho wrote:
> > > If DF can be used to fragment a bundle, and all bundles are treated the
> > > same, then DF can be used to fragment a conventional fragment, 
> right?  And
> > > in fact DF can also be used to fragment a bundle whose payload is a 
> DF code
> > > block, right?
> >
> > yup, if you really care to do that
>
>I would prefer keeping it to single level fragmentation, which is in
>keeping with the protocol spec.

I think the protocol spec says you can fragment a bundle, not that you can 
only fragment a non-fragmentary bundle.  If so, the spec already supports 
multi-level fragmentation.

> > > If the only type of protocol data unit we've got in Bundling is Bundles,
> > > then the only thing you can take custody of is a bundle, yes?  If not,
> > > we've got a profound architectural change: "partial custody 
> transfer", the
> > > ancient "bindling" argument.
>
>Oh so "bindling" is actually a word and not a misspelling.  I would say
>this is not a profound architectural change - just a gray area that hadn't
>been implemented and now needs clarification.

Except that I think it's currently not a gray area at all: you take custody 
of bundles, period.  If the bundle happens to be a fragmentary bundle, 
well, okay, you're taking custody of a fragmentary bundle; the previous 
custodian needs to recognize this by replicating the fragmentation after 
the fact (if necessary) and releasing custody of the fragment identified in 
the custody ack.

> > > introduced additional complexity into the protocol.  If so, any 
> custodial
> > > retransmission that applies to DF-based fragments is redundant.
>
>I should clarify. The way I wanted to approach custody transfer of DF
>fragments was a mechanism for optimization rather than additional
>complexity. Let's assume that, as the one who fragmented the bundle, you
>can't release custody until all of the custody acks for the bundle
>fragments have arrived. If it is df fragmentation, then you don't need to
>wait for all of the custody acks - just a percentage of them.

But I think that's not the right assumption, so in this case df 
fragmentation is solving a non-problem.

>Oh so whether custody makes sense for df, I think it might.  You might
>want to make ensure delivery of the code blocks once they have been
>generated. The difference is that you don't need as high reliabilty as
>before since you can afford to lose some custodially transferred bundles.
>You might do this if you expect a lot of dead ends in routing.
>
> > > forwarding a cornerstone of delay-tolerant networking.  The additional
> > > complexity imposed by these devices is amply justified in the 
> environments
> > > where they are needed, but not in the core of bundling that everybody 
> has
> > > to work with.  Let's implement them in convergence layer adapters where
> > > they are required, rather than jam them down the throats of 
> developers and
> > > users who do not want or need them.  Let's be modular.  Let's try to 
> avoid
> > > making CFDP's mistakes all over again.
>
>Right so we also want to make dtn be something that actually adds value to
>and reduces complexity of these systems. I think we can make the error of
>making bundling too complex, but I also think we can make the error of
>being so generalized that we don't achieve something useful.  Custody
>transfer and fragmentation are extensions that we think some number of
>people implementing delay tolerant networks will need. I believe erasure
>coding falls into this category as well.

I believe that too.  I just don't think that means that erasure coding has 
to be built into the bundling protocol.

I mean, there is no stigma in being implemented within a convergence layer 
adapter that enables bundling to run successfully in a given type of 
region, rather than in the overlay network protocol itself.  The fact that 
bundling is higher in the stack is an artifact of typography, not a 
reflection of the natural order of things.  Being bundling doesn't mean 
you're the Important Part of the architecture.

It doesn't bother me that bundling might end up quite small and simple if 
we leave DF out of it; I like small and simple, it often means "working".

We certainly don't want bundling to be so generalized that it doesn't do 
anything useful.  But if bundling does nothing but deferred transmission, 
store-and-forward, trans-regional routing, and options for inter-node 
suspicion, custody transfer, congestion control, resilient delivery, 
payload security, and some priority and reporting features, then I think it 
is doing quite a lot of useful stuff.  Let's do some other useful stuff 
somewhere else.

Scott 

Date: Tue, 06 Apr 2004 16:06:56 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: RE: [dtn-interest] fragmentation and erasure coding in Bundling
Sender: [email-masked]

At 06:07 PM 4/6/2004 -0400, Robert C. Durst wrote:

> >
> >We DO have to write a single, unambiguous, comprehensive
> >specification for
> >the Bundling protocol, and every single compliant
> >implementation of that
> >protocol has got to implement all of it.  That is what
> >protocol design is
> >all about.
>
>Scott, I believe that this is a central part of the issue at hand.
>
>While I agree with the first part of your statement, I personally do NOT
>believe that "every single compliant implementation of [bundling] has to
>implement all of [the protocol specification]."  I believe that optional
>capability is perfectly valid, has great precedent, and an approach
>specifying "profiles" of the protocol for particular Delay Tolerant Networks
>was what we had in mind when we broadened our scope from IPN to DTN.  I
>believe that interoperability within profiles is an absolute necessity, but
>across profiles is an implementation and marketing decision.

Okay, a good point.

I think we agree that Bundling is a single protocol for which we must have 
a single, unambiguous, comprehensive specification, but that this 
specification might include procedures that are optional (meaning there can 
be statements like "when X occurs, procedure Y MAY be performed -- and if Y 
is performed it must be done in the following way").

If by a "profile" we mean not just an ops concept or deployment scenario 
but instead some formal, comprehensive list of specific optional procedures 
in the spec that MUST be performed by any implementation that is to be 
considered compliant with that profile, then I agree that a profile-based 
approach is valid and has plenty of precedent.

Judging from my experience with defining CFDP's "service classes" (same 
idea), I think we would be opening ourselves up to a world of pain in 
taking this approach.  It is hard enough to make sure that all cases are 
addressed in a protocol design where everything is fixed; it is much harder 
to assure the same level of coverage for multiple profiles, making sure 
that no procedure that is mandatory in one profile is dependent on any 
other procedure that is optional in that profile.

I think developing a spec in this way will either take a lot longer or 
contain a lot more errors, or both, and the resulting document will be 
significantly larger, more challenging to read, and more daunting to 
implement from.  I really think we would be much better off partitioning 
the DTN architectural problem into (a) a relatively small, simple bundling 
specification and (b - z) some number of likewise relatively small, simple 
convergence layer adapter specifications suited to various types of 
environmental region.

It is not my intent to be obstructionist or Luddite here, I swear it 
isn't.  I just want us all to succeed.  In my experience, big projects 
fail; big systems don't work; big documents are unreadable, or at least 
unread.  What works is the gradual accretion of a lot of small things, each 
done well, that make up successful Big Things when you hook them 
together.  Let's do a little bit, and get that right, and then do some more.

Scott 

Date: Tue, 6 Apr 2004 18:37:30 -0400 (EDT)
From: Melissa Ho <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] fragmentation and erasure coding in Bundling
Sender: [email-masked]

For reactively fragmenting erasure coded bundles:
* using small code blocks does in fact make sense, because it gives us 
granularity in how much overhead we have.
* given this, we can reactively fragment exactly the same way as normal 
fragmentation is done. cut the bundle off wherever transmission ends, and 
you get however many complete code blocks actually made it through.
* on the sending side, you just generate more code blocks, so you don't 
have to worry about which code block got cut off.
* if you aren't the source, umm.. make sure to cut the data at an offset 
that is a multiple of the code block length specified in the header.
* this way, we still have single level fragmentation

notes:
* the intermediate router shouldn't put a fragment header on a df-encoded 
bundle
* in fact, df fragment headers should not coexist with fragment headers

For QoS on fragments (df or otherwise):
* its a bundle, treat it the same as any other bundle, or, if you 
subscribe to my custody-over-original-bundles idea, then its a non issue.
* return receipts - instinctively i would worry that you could accidentaly 
flood the returnto with receipts, because it expects one and suddenly gets 
a lot. however, if you remember that we are doing fragmentation for the 
sake of fitting into short contacts, or splitting across a few channels, 
we shouldn't end up with that many fragments!

> > One impression I got [...] was this: maybe we don't 
> > all agree that adding erasure coding as an alternative fragmentation 
> > mechanism within bundling itself (as opposed to an end-to-end system above 
> > bundling or a convergence-layer system underneath bundling) would 
> > necessarily have a huge impact on the DTN architecture and the Bundling 
> > protocol spec.  It's just one additional header, after all.

Okay.. I'm going to take it from this point of view: I want to see if 
there is a way to integrate fragmentation and erasure coding with a 
minimal impact to DTN architecture and Bundling protocol. Given that 
erasure coding is not yet a part of the protocol, there is necessarily 
*some* impact.  New headers should not be considered a "huge impact", but 
I also realize that changes to the protocol can be highly impactful.

> > When Bundling uses DF to fragment a bundle, issuing code blocks, are the 
> > code blocks issued in bundles, or are they issued in some other type of
> > protocol data unit?  If the latter, we've got a profound architectural change.

Bundles. Definitely. The fact that it is DF-encoded will be indicated in 
the header. 

> > If the code blocks are issued in bundles, are these bundles treated the 
> > same way as all other bundles (except, obviously, for the procedures used 
> > to reconstitute original bundles from them), or are there now two different 
> > classes of bundles that are treated differently by bundle agents?  If the 
> > latter, we've got a profound architectural change that seriously 
> > complicates the protocol.
> 
> just re-constitution

I would say this is undecided. Should custody be over any bundle, or 
should custody be over matching timestamp-src-destination? For now I'll 
pursue the custody over bundles (fragment or otherwise) and see if that 
works. So I'm willing to suspend this issue until I have thought it 
through completely.

> > If so, 
> > each one has to be uniquely identifiable (to enable conventional
> > reassembly); what uniquely identifying bundle ID extension accomplishes 
> > this?  When a DF code block is reactively fragmented, what do those
> > fragments look like?  Is the key (etc.) stuff of the DF code block carried 
> > only in the first of those fragments?
The key is part of the bundle payload - each code-block is preceded by its 
matching key. For the open source version, its just a sequence number.

> > If DF can be used to fragment a bundle, and all bundles are treated the 
> > same, then DF can be used to fragment a conventional fragment, right?  And
> > in fact DF can also be used to fragment a bundle whose payload is a DF code 
> > block, right?
> 
> yup, if you really care to do that

I would prefer keeping it to single level fragmentation, which is in 
keeping with the protocol spec. 

> > If the only type of protocol data unit we've got in Bundling is Bundles, 
> > then the only thing you can take custody of is a bundle, yes?  If not, 
> > we've got a profound architectural change: "partial custody transfer", the 
> > ancient "bindling" argument.
> 

Oh so "bindling" is actually a word and not a misspelling.  I would say 
this is not a profound architectural change - just a gray area that hadn't 
been implemented and now needs clarification.

> > introduced additional complexity into the protocol.  If so, any custodial 
> > retransmission that applies to DF-based fragments is redundant.

I should clarify. The way I wanted to approach custody transfer of DF 
fragments was a mechanism for optimization rather than additional 
complexity. Let's assume that, as the one who fragmented the bundle, you 
can't release custody until all of the custody acks for the bundle 
fragments have arrived. If it is df fragmentation, then you don't need to 
wait for all of the custody acks - just a percentage of them.

Oh so whether custody makes sense for df, I think it might.  You might 
want to make ensure delivery of the code blocks once they have been 
generated. The difference is that you don't need as high reliabilty as 
before since you can afford to lose some custodially transferred bundles. 
You might do this if you expect a lot of dead ends in routing.

> > forwarding a cornerstone of delay-tolerant networking.  The additional 
> > complexity imposed by these devices is amply justified in the environments 
> > where they are needed, but not in the core of bundling that everybody has 
> > to work with.  Let's implement them in convergence layer adapters where 
> > they are required, rather than jam them down the throats of developers and 
> > users who do not want or need them.  Let's be modular.  Let's try to avoid 
> > making CFDP's mistakes all over again.

Right so we also want to make dtn be something that actually adds value to
and reduces complexity of these systems. I think we can make the error of
making bundling too complex, but I also think we can make the error of
being so generalized that we don't achieve something useful.  Custody
transfer and fragmentation are extensions that we think some number of
people implementing delay tolerant networks will need. I believe erasure
coding falls into this category as well.

Melissa

Date: Tue, 06 Apr 2004 15:35:25 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] fragmentation and erasure coding in Bundling
Sender: [email-masked]

At 02:49 PM 4/6/2004 -0700, Kevin Fall wrote:
> >
> > You're right, that doesn't matter, but neither is it fundamental.  If it
> > doesn't apply to all possible deployments of Bundling, it's not really
> > fundamental.
>
>do you believe only 'fundamental' things (by your definition) should be 
>implemented in bundling...?

A fair question.  I guess I think that the bundling protocol itself should 
ideally comprise only the procedures necessary for forwarding bundles 
securely through a network where the links between nodes are subject to 
long signal propagation delays and/or relatively frequent interruption, 
together with QoS, security, and delivery features that we think might 
reasonably be useful to applications.  I think the list includes deferred 
transmission, store-and-forward, trans-regional routing, and options for 
inter-node suspicion, custody transfer, congestion control, resilient 
delivery, payload security, and some priority and reporting features.

Limited in this way, bundling is really pretty simple.  I think this has a 
couple of advantages:

-       Implementations of the bundling protocol can be compliant and yet 
(potentially) tiny, so that bundling can run on very small platforms.

-       When you deploy bundling in a "regional" environment that is itself 
pretty simple, such as an LAN or a simple deep-space network configuration, 
the combination of bundling and its region-specific convergence layer can 
be small enough to be suitable for small processors.

-       When you deploy bundling in a more complex regional environment, 
the additional complexity is limited to just what is necessary for 
operation in that environment.  A region-specific convergence layer can do 
arbitrarily complex intra-regional routing in ways that are applicable to 
that environment, without the overhead of other routing considerations that 
are relevant only in other environments.

-       Partitioning the DTN functionality in this way can make 
implementation and software maintenance easier, reducing the incidence of 
bugs and enabling concurrent work by people with different domains of 
expertise.

Scott 

From: "Robert C. Durst" <[email-masked]>
To: "'Scott Burleigh'" <[email-masked]>, <[email-masked]>
Subject: RE: [dtn-interest] fragmentation and erasure coding in Bundling
Date: Tue, 6 Apr 2004 18:07:10 -0400
Organization: The MITRE Corporation
Sender: [email-masked]

>
>We DO have to write a single, unambiguous, comprehensive 
>specification for 
>the Bundling protocol, and every single compliant 
>implementation of that 
>protocol has got to implement all of it.  That is what 
>protocol design is 
>all about.

Scott, I believe that this is a central part of the issue at hand.

While I agree with the first part of your statement, I personally do NOT
believe that "every single compliant implementation of [bundling] has to
implement all of [the protocol specification]."  I believe that optional
capability is perfectly valid, has great precedent, and an approach
specifying "profiles" of the protocol for particular Delay Tolerant Networks
was what we had in mind when we broadened our scope from IPN to DTN.  I
believe that interoperability within profiles is an absolute necessity, but
across profiles is an implementation and marketing decision.  

Take care,
Durst

To: Scott Burleigh <[email-masked]>
cc: [email-masked]
Subject: Re: [dtn-interest] fragmentation and erasure coding in Bundling 
Date: Tue, 06 Apr 2004 14:49:33 -0700
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

> 
> You're right, that doesn't matter, but neither is it fundamental.  If it 
> doesn't apply to all possible deployments of Bundling, it's not really 
> fundamental.

do you believe only 'fundamental' things (by your definition) should be implemented in bundling...?

- K

Date: Tue, 06 Apr 2004 14:34:59 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] fragmentation and erasure coding in Bundling
Sender: [email-masked]

At 02:12 PM 4/6/2004 -0700, Kevin Fall wrote:
> >
> > From:  Scott Burleigh <[email-masked]>
> > To:    [email-masked]
> > Subject: Re: [dtn-interest] fragmentation and erasure coding in Bundling
> > Date:  Tue, 06 Apr 2004 13:27:27 PDT
> >
> > At 09:51 AM 4/6/2004 -0700, Kevin Fall wrote:
> > >Well, hmm.  So this is the realm of opinion I guess.  I believe that
> > >there are two primary things dtn wishes to accomplish:  handle 
> disconnection
> > >reasonably well, and handle interoperability across very heterogeneous
> > >networks.  To handle disconnection we have the concepts of contacts
> > >and an interesting routing problem becomes to "fill" them.  In a broad
> > >range of cases there are multiple paths available (because of the "new
> > >ability"
> > >to handle heterogeneous devices [think: 'if I have any connection 
> possible
> > >I can
> > >make use of it with DTN']) and in some of those simultaneous use will be
> > >desirable.  Fragmentation is for two things:  1> what to do to large 
> message
>s
> > >so you can send them over multiple paths, perhaps simultaneously, and 
> 2> wha
>t
> > >to do with a large message while, during a transfer at a link, you 
> encouter
> > >an interruption but you still want to make use of that data that did 
> arrive.
> > >#2 is the 'reactive fragmentation' concept, and it is a performance
> > >optimization.
> > >If the "main routing" is functioning properly and there are no unexpected
> > >interruptions
> > >you should never see it happening.
> >
> > Except that you will also see it happening when, during transfer of a 
> large
> > message, you encounter an *expected* interruption and you still want to
> > make use of the data that did arrive.  That is, #2 also covers the case of
> > sending a large message over a single path in multiple episodes.  This can
> > be an entirely nominal operating scenario, and in fact it will be 
> pervasive
> > in deep space communications -- you will see it happening all the time.
>
>So, it should be pointed out here I suppose that I do not agree with
>Keith that fragmentation could live underneath bundling and in a convergence
>layer in order to achieve my objectives.  This is assuming that a convergence
>layer interface represents an address family boundary (my general assumption).
>
>Also, I do not expect reactive fragmentation to be used for expected 
>interruption.
>Expected interruption would be a thing known to the bundle routing layer.
>This is because knowing the set of contacts ahead of time allows the
>bundle layer (the routing piece that decides how to perform splits, in 
>particular)
>to choose among multiple paths and to choose good split sizes.  Trying to do
>this reactively requires the system to make a best-guess estimate of what
>actually made it across the link; possible perhaps, but almost certainly
>less likely to be accurate versus a contact known a-priori.

This is odd: I would say exactly the opposite.  The information provided by 
the underlying transport layer, it seems to me, would be informed by 
reality, while the information in the contact list used for route planning 
would be informed only by expectation.  I would always prefer protocol 
activity to be driven by events rather than by plans, as much as possible, 
because the universe is so much better a model for itself than anything we 
can compute.

>Also, it allows for: revocation/cancelling in case there is a decision not 
>to send, the ability
>to time-out bundles in the bundle layer while parts are waiting,
>the ability to change routing decisions between contacts , aggregate 
>fragements and perhaps
>perform additional processing on them [user-defined functions--- something 
>in the future perhaps],
>transcode, perform replication in case path delivery probabilities
>are not so high, and it minimizes queueing within a CL.  I believe CL's
>should have absolute minimum buffering and no routing.  To push
>the point, routing is perhaps the only really meaty problem of bundling 
>and that's
>the main thing it should be doing.

These are all implementation issues; we disagree on them, but that is 
unimportant so long as the protocol design doesn't preclude either view.

> > Of course, at this point I have to agree that support for this scenario,
> > like support for mobile tactical networks, is not central to the operation
> > of Bundling; there are plenty of environments that would not be
> > characterized by this sort of operation.
>
>I think interruption during message xfer is representative of virtually
>all scenarios we have discussed. (as below)
>
> > So maybe Keith has a point, maybe
> > reactive fragmentation too belongs only in the convergence layer.
> > I think
> > a counter-argument, though, might be that reactive fragmentation is also a
> > defense against unexpected interruptions, which I imagine are possible in
> > any DTN environment whatsoever.  As such I think it qualifies as an error
> > handling measure that needs to be in the common core of bundling.
>
>yes, I agree
>
> > >I cannot address multicast with as much clarity.  Lots of networking
> > >experience
> > >has shown us that reliable multicasting at large scale is 
> difficult.  Howeve
>r,
> > >for smaller scale its not so difficult.  It is
> > >certainly more complex.  Should DTN support 'small-scale' multicast?
> > >I'm not completely sure, but if the answer is 'no' then we have to do it
> > >on top.
> > >That would amount to a reliable multicast overlay on top of dtn, which 
> is an
> > >overlay itself [gag], so my inclination would be to embrace multicast 
> at lea
>st
> > >at some point.  However, in order to maintain progress with our
> > >current direction, I'm willing to forego the mcast part while we get
> > >fragmentation working properly.  [of course, there's also security to do
> > >too :<>].
> >
> > I'm not too bothered by the difficulty of multicast; if it's needed, and
> > it's possible, then we should do it.  Again, though, my concern that it 
> has
> > been way too easy to festoon Bundling with cheerful bells and whistles 
> that
> > make it fun to write about but difficult to sell to real users, who may 
> not
> > need those particular bells and those particular whistles.  The fact that
> > we've been able to demonstrate Bundling with a relatively straight face at
> > JPL, without even a hint of multicast support, suggests to me that it is
> > not a core feature of the protocol.
>
>IMHO, what has been required by JPL to date appears to be significantly 
>limited versus some of the
>other environments we wish to consider.

Well, I can't argue with you there.

Scott 

Date: Tue, 06 Apr 2004 14:25:41 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: RE: [dtn-interest] fragmentation and erasure coding in Bundling
Sender: [email-masked]

At 02:35 PM 4/6/2004 -0400, Keith Scott wrote:
> >> If bundles whose payloads are DF code blocks (rather than
> >conventional
> >> fragments) are treated just like all other bundles, then they must be
> >> subject to reactive fragmentation like all other bundles, right?
> >
> >yes
> >
> >> If so,
> >> each one has to be uniquely identifiable (to enable conventional
> >> reassembly); what uniquely identifying bundle ID extension
> >accomplishes
> >> this?  When a DF code block is reactively fragmented, what do those
> >> fragments look like?  Is the key (etc.) stuff of the DF code
> >block carried
> >> only in the first of those fragments?
> >
> >the simplest version would be to do conventional reactive frag if this
> >happens (which would entail creating new frag headers with the
> >appropriate info in them as would be normal).  There is a
> >"fancier idea" we've been kicking around about
> >actually munging the contents of the codeblock into parts, but this
> >is still sort of open.
> >
>
>I think the point is that since the (source entity ID, sending timestamp)
>would presumably be the same for all DF-encoded fragments of the same bundle
>(since this tuple is what uniquely identifies the association among
>fragments) we would have to introduce some other field for bundles that were
>DF-encoded and then had their DF codeblock (bundles) further fragmented.
>The purpose of this field would be to allow the fragments to be correctly
>associated before DF decoding takes place.  To be extremely concrete, if two
>separate DF codeblocks were fragged into 100-byte chunks, there would be two
>bundles with the same (source entity ID, sending timestamp) and fragment
>offset 0 length 100.

Yes, that is my concern.

>I think the notion of having the DF fragmentation
>process generate lots o' little fragments (~ 40 bytes each) so that they can
>be arbitrarily split _without_ the complication Scott envisions (i.e. no
>need for an additional identifying extension) is your open issue?  I still
>don't like the lots of little codeblocks approach, due to perceived
>overhead.
>
> >> If custodial delivery propagates to all fragments of the
> >original bundle to
> >> which it was applied, then custodial delivery propagates to
> >fragmentary
> >> bundles resulting from DF encoding -- and to the
> >conventional and/or DF
> >> fragments into which those fragments might be divided.  Are custody
> >> transfer procedures the same for those fragments as for the original
> >> bundle?  If not, we're not treating all bundles the same; we have
> >> introduced additional complexity into the protocol.  If so,
> >any custodial
> >> retransmission that applies to DF-based fragments is redundant.
> >
> >That might change, which I see might be like this.  If you are
> >using an error correcting
> >code and you successfully custody xfer some threshold
> >percentage of them to other
> >custodians then you assume you have successfully moved custody
> >along.  This
> >is different, but I think would lead to little code
> >complexity.  The difference amounts
> >to whether you use one ACK or multiple ACKs in order to assume
> >you have done
> >your job.
> >
>
>I agree that this is a complicated area, but not that this introduces any
>architecture-breaking complexity into the protocol.  It might be as simple
>as:
>
>1) You SHOULD NOT apply DF-encoding to custodially transmitted bundles,
>since it would cause all the DF codeblocks to be custodially delivered which
>is silly.

An increment of complexity.  Not a killer, certainly.  None of these little 
changes are killers in themselves.

>2) If you apply DF-encoding to custodially transmitted bundles, then you
>MUST first employ bundle-in-bundle encapsulation (to preserve the current
>custodian in the inner bundle) and then apply DF; the DF codeblocks MUST NOT
>have custody set.

Which is a little like the tunneling approach I proposed a while 
ago?  Except that now every compliant bundling implementation has to know 
how to do this.

>This leaves the DF-fragmenter as the stuckee until either
>the bundle is opportunistically DF-decoded (at which time the decodee or any
>downstream node may elect to take custody) or, more probably (at least the
>way I usually think about things) until the DF-fragments hit the ultimate
>destination.
>3a) You must do tunneling as well if you want to DF-encode a fragment (this
>is a non-invasive way of getting a separate unique identifier for the DF
>codeblock bundles)
>3b) We have some rules about which headers appear and are processed in what
>order.

Which we haven't even started talking about yet, and which currently we can 
manage without because we don't have to deal with this complexity.

> >> What about custody transfer for conventional fragments of DF
> >fragments?  Do
> >> we bother to do it, since it's at cross-purposes with the DF
> >encoding?  If
> >> not, we have introduced another little increment of
> >complexity into the
> >> protocol.
> >
> >It could be allowed.  It just doesn't necessarily seem to
> >offer profound
> >benefits.
> >
>
>Presumably a fragment of a single codeblock is useless, and so must be
>reunited with its brethren before it can be presented to a DF decoder.  I
>think the answer to this is tied up in the above question of what to do
>about DF AND regular fragmentation.  It would seem to be a requirement for
>the case where some router does DF encoding and ends up with codeblocks that
>are too large to transit some downstream region.

This sounds to me like quite a few open architectural issues to sort out, 
resulting in an indeterminate number of changes to the bundling protocol 
spec and the implementations.

> >> If an application requests some other QoS service for an
> >application data
> >> unit, such as reception reporting, does that QoS propagate
> >to all fragments
> >> of the resulting bundle?  If not, we've got a significant
> >architectural chang
> >e.
> >
> >I'm not sure.  It may depend.  I am reminded about ICMP messages for
> >fragments.  In that case, there are particular rules that
> >apply to fragments,
> >and I would be terribly surprised if we end up going in a
> >similar direction.
> >But I also don't think this should pose too much of a problem.
> > Indeed, my
> >hunch is that frags would be treated as bundles generally, but in the
> >particular e2e ack case we have available you would need the
> >entire thing
> >to be at the final dest (which is the case anyhow).
>
>Yes, what do we do about that with regular fragmentation?

Propagate the QoS to all fragmentary bundles, send reception reports back 
to the Report-to endpoint whenever a bundle (fragmentary or not) is received.

> >> If reception reporting propagates to all fragments of the
> >original bundle
> >> to which it was applied, then reception reporting propagates
> >to fragmentary
> >> bundles resulting from DF encoding -- and to the
> >conventional and/or DF
> >> fragments into which those fragments might be divided.  This
> >could result
> >> in some pretty baffling and useless reports being passed
> >back to the source
> >> application.  If we don't do this, we're not treating all
> >bundles the same;
> >> we have introduced additional complexity into the protocol.
> >
> >why would it be baffling?

Because each such report would be telling the Report-to about the reception 
of some data that it knows nothing about: it's a DF code block, not 
any  contiguous extent of the original application data unit.

>Also, recall that the reports don't need
> >to be sent back to the source.

Of course that's right, I should have said "back to the Report-to endpoint".

>Although I'm not sure of this, if you
> >frag an IP packet with a low ttl and the frags are, say,
> >routed in different
> >paths and they expire in-transit... I believe you get an ICMP
> >indication for
> >each... but I would have to check that.
> >
>
>Yes, what do we do about that with regular fragmentation?

The reception reports that manage to arrive tell the Report-to endpoint 
what pieces of the bundle were received at which nodes at what times.  The 
ones that disappear when TTL expires don't get to tell their story; but of 
course neither would the sole reception report issued on complete bundle 
reception at the final destination, if its TTL expired before it got delivered.

> >> These are the only points I can think of off the top of my
> >head, without
> >> any of the documents in front of me.  If we start down this path in
> >> earnest, of course, we will have to go through the spec and the
> >> architecture draft in detail to see what else must be addressed.
> >>
> >> All of which would obviously be worthwhile if erasure coding
> >were a central
> >> and indispensable capability for delay-tolerant networking.
> >It is not.
>
>Neither is fragmentation.

We disagree, although if you had said "neither is conventional 
fragmentation" I would agree with you.

Without fragmentation of some sort, it is impossible to convey a bundle 
when contact period is too short, or data rate is too low, to transmit all 
bytes before the contact ends.  Either conventional fragmentation or 
erasure coding would work for this purpose.  I argued in my last response 
to Kevin that reactive conventional fragmentation addresses a wider range 
of problems than erasure coding does, possibly including problems that are 
not environment-specific, but that may not be self-evident.

> >> Certainly it will be extremely valuable in a number of environments,
> >> possibly a very large number: it's a great way to do
> >multi-path routing,
> >> and it's a great way to do multicast.  But in 18 years of
> >network systems
> >> development at JPL I have never seen an application that needed
> >> multicast.
>
>Multicast is probably as large a driver for the military as small code
>footprint is for space missions.  Something like 80% of the Army's traffic
>is multicast.  It is an absolute requirement for their environment  They
>have lots of 'everybody needs to know this' traffic (like: here's where I
>am, don't shoot here), and really low capacity links.

Sure.  I said so, one paragraph below here.

> >> I have seen maybe one application that could have used
> >> multi-path routing, to compensate for some deficiencies in network
> >> design.  You don't need multicast when there's only a single
> >destination;
> >> you don't need multi-path when there's only a single path,
> >or when any
> >> single path is sufficient to carry your message.
> >Applications with these
> >> characteristics will be with us for a long time.
>
>One of the main advantages people tout about SCTP is its ability to do
>multi-path message transfer.  SCTP was moved out of sigtrans into the
>transport area specifically because people saw use for it as a general
>purpose transport protocol for new applications.

Sure.  There will be lots of applications where multi-path will be 
needed.  I said something like that, in my next paragraph.

> >> I do not doubt for an instant that multi-path and multicast
> >are needed for
> >> military applications, especially mobile tactical
> >applications; I don't
> >> doubt for an instant that the Internet needs multicast for
> >information
> >> streaming, nor that it needs multi-path for mobile applications.  We
> >> certainly have got to support this stuff.
>
>Right.  And I believe that we can support them by saying, in the
>specification, something like: If you want to do FEC encoding, here's how to
>do it.  Here are situations where we know it will be silly, and here are
>some other (informative) guidelines.  We do NOT have to require that every
>implementation provide DF-decoding services.

We DO have to write a single, unambiguous, comprehensive specification for 
the Bundling protocol, and every single compliant implementation of that 
protocol has got to implement all of it.  That is what protocol design is 
all about.

> >> What we don't need to do, though, is make it a cornerstone of
> >> delay-tolerant networking, any more than we need to make
> >ephemerides-aware
> >> forwarding a cornerstone of delay-tolerant networking.
>
>The concept of 'scheduled connectivity' (in addition to predicted and
>opportunistic) is fundamental to DTN.  It doesn't matter whether that
>schedule is dictated by physics or military doctrine.

You're right, that doesn't matter, but neither is it fundamental.  If it 
doesn't apply to all possible deployments of Bundling, it's not really 
fundamental.

> >>  The
> >additional
> >> complexity imposed by these devices is amply justified in
> >the environments
> >> where they are needed, but not in the core of bundling that
> >everybody has
> >> to work with.  Let's implement them in convergence layer
> >adapters where
> >> they are required, rather than jam them down the throats of
> >developers and
> >> users who do not want or need them.  Let's be modular.
> >Let's try to avoid
> >> making CFDP's mistakes all over again.
>
>While possibly powerful tools within convergence layers, these tools are
>much more powerful if they can be applied to bundle transfer as a whole
>rather than forcing all traffic through a single regional exit point.  By
>forcing this functionality (which includes regular fragmentation, BTW) into
>convergence layers, we LOSE the ability to exploit multiple paths through
>the network.  This is fine for deep-space communications, where there is
>exactly one path, but that (hopefully) isn't going to be everyone's model.

If you have got multiple paths through a region, and the region is in a 
network, haven't you got multiple paths through the network?  So how have 
you lost the ability to exploit them?  Why isn't this just a matter of 
drawing region boundaries in such a way that your multiple intra-region 
paths are the intra-network paths you need?  Why have we got to bloat 
Bundling itself with this stuff?

Scott 

To: Scott Burleigh <[email-masked]>
cc: [email-masked]
Subject: Re: [dtn-interest] fragmentation and erasure coding in Bundling 
Date: Tue, 06 Apr 2004 14:12:04 -0700
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

>
> From:  Scott Burleigh <[email-masked]>
> To:    [email-masked]
> Subject: Re: [dtn-interest] fragmentation and erasure coding in Bundling
> Date:  Tue, 06 Apr 2004 13:27:27 PDT
>
> At 09:51 AM 4/6/2004 -0700, Kevin Fall wrote:
> >Well, hmm.  So this is the realm of opinion I guess.  I believe that
> >there are two primary things dtn wishes to accomplish:  handle disconnection
> >reasonably well, and handle interoperability across very heterogeneous
> >networks.  To handle disconnection we have the concepts of contacts
> >and an interesting routing problem becomes to "fill" them.  In a broad
> >range of cases there are multiple paths available (because of the "new 
> >ability"
> >to handle heterogeneous devices [think: 'if I have any connection possible 
> >I can
> >make use of it with DTN']) and in some of those simultaneous use will be
> >desirable.  Fragmentation is for two things:  1> what to do to large message
s
> >so you can send them over multiple paths, perhaps simultaneously, and 2> wha
t
> >to do with a large message while, during a transfer at a link, you encouter
> >an interruption but you still want to make use of that data that did arrive.
> >#2 is the 'reactive fragmentation' concept, and it is a performance 
> >optimization.
> >If the "main routing" is functioning properly and there are no unexpected 
> >interruptions
> >you should never see it happening.
> 
> Except that you will also see it happening when, during transfer of a large 
> message, you encounter an *expected* interruption and you still want to 
> make use of the data that did arrive.  That is, #2 also covers the case of 
> sending a large message over a single path in multiple episodes.  This can 
> be an entirely nominal operating scenario, and in fact it will be pervasive 
> in deep space communications -- you will see it happening all the time.

So, it should be pointed out here I suppose that I do not agree with
Keith that fragmentation could live underneath bundling and in a convergence
layer in order to achieve my objectives.  This is assuming that a convergence
layer interface represents an address family boundary (my general assumption).

Also, I do not expect reactive fragmentation to be used for expected interruption.
Expected interruption would be a thing known to the bundle routing layer.
This is because knowing the set of contacts ahead of time allows the
bundle layer (the routing piece that decides how to perform splits, in particular)
to choose among multiple paths and to choose good split sizes.  Trying to do
this reactively requires the system to make a best-guess estimate of what
actually made it across the link; possible perhaps, but almost certainly
less likely to be accurate versus a contact known a-priori.
Also, it allows for: revocation/cancelling in case there is a decision not to send, the ability
to time-out bundles in the bundle layer while parts are waiting,
the ability to change routing decisions between contacts , aggregate fragements and perhaps
perform additional processing on them [user-defined functions--- something in the future perhaps],
transcode, perform replication in case path delivery probabilities
are not so high, and it minimizes queueing within a CL.  I believe CL's
should have absolute minimum buffering and no routing.  To push
the point, routing is perhaps the only really meaty problem of bundling and that's
the main thing it should be doing.

> Of course, at this point I have to agree that support for this scenario, 
> like support for mobile tactical networks, is not central to the operation 
> of Bundling; there are plenty of environments that would not be 
> characterized by this sort of operation.

I think interruption during message xfer is representative of virtually
all scenarios we have discussed. (as below)

> So maybe Keith has a point, maybe 
> reactive fragmentation too belongs only in the convergence layer.
> I think 
> a counter-argument, though, might be that reactive fragmentation is also a 
> defense against unexpected interruptions, which I imagine are possible in 
> any DTN environment whatsoever.  As such I think it qualifies as an error 
> handling measure that needs to be in the common core of bundling.

yes, I agree

> 
> >I cannot address multicast with as much clarity.  Lots of networking 
> >experience
> >has shown us that reliable multicasting at large scale is difficult.  Howeve
r,
> >for smaller scale its not so difficult.  It is
> >certainly more complex.  Should DTN support 'small-scale' multicast?
> >I'm not completely sure, but if the answer is 'no' then we have to do it 
> >on top.
> >That would amount to a reliable multicast overlay on top of dtn, which is an
> >overlay itself [gag], so my inclination would be to embrace multicast at lea
st
> >at some point.  However, in order to maintain progress with our
> >current direction, I'm willing to forego the mcast part while we get
> >fragmentation working properly.  [of course, there's also security to do 
> >too :<>].
> 
> I'm not too bothered by the difficulty of multicast; if it's needed, and 
> it's possible, then we should do it.  Again, though, my concern that it has 
> been way too easy to festoon Bundling with cheerful bells and whistles that 
> make it fun to write about but difficult to sell to real users, who may not 
> need those particular bells and those particular whistles.  The fact that 
> we've been able to demonstrate Bundling with a relatively straight face at 
> JPL, without even a hint of multicast support, suggests to me that it is 
> not a core feature of the protocol.

IMHO, what has been required by JPL to date appears to be significantly limited versus some of the
other environments we wish to consider.

- K

Date: Tue, 06 Apr 2004 13:27:27 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] fragmentation and erasure coding in Bundling
Sender: [email-masked]

At 09:51 AM 4/6/2004 -0700, Kevin Fall wrote:
>Well, hmm.  So this is the realm of opinion I guess.  I believe that
>there are two primary things dtn wishes to accomplish:  handle disconnection
>reasonably well, and handle interoperability across very heterogeneous
>networks.  To handle disconnection we have the concepts of contacts
>and an interesting routing problem becomes to "fill" them.  In a broad
>range of cases there are multiple paths available (because of the "new 
>ability"
>to handle heterogeneous devices [think: 'if I have any connection possible 
>I can
>make use of it with DTN']) and in some of those simultaneous use will be
>desirable.  Fragmentation is for two things:  1> what to do to large messages
>so you can send them over multiple paths, perhaps simultaneously, and 2> what
>to do with a large message while, during a transfer at a link, you encouter
>an interruption but you still want to make use of that data that did arrive.
>#2 is the 'reactive fragmentation' concept, and it is a performance 
>optimization.
>If the "main routing" is functioning properly and there are no unexpected 
>interruptions
>you should never see it happening.

Except that you will also see it happening when, during transfer of a large 
message, you encounter an *expected* interruption and you still want to 
make use of the data that did arrive.  That is, #2 also covers the case of 
sending a large message over a single path in multiple episodes.  This can 
be an entirely nominal operating scenario, and in fact it will be pervasive 
in deep space communications -- you will see it happening all the time.

Of course, at this point I have to agree that support for this scenario, 
like support for mobile tactical networks, is not central to the operation 
of Bundling; there are plenty of environments that would not be 
characterized by this sort of operation.  So maybe Keith has a point, maybe 
reactive fragmentation too belongs only in the convergence layer.  I think 
a counter-argument, though, might be that reactive fragmentation is also a 
defense against unexpected interruptions, which I imagine are possible in 
any DTN environment whatsoever.  As such I think it qualifies as an error 
handling measure that needs to be in the common core of bundling.  But 
maybe that's an open question.

>I cannot address multicast with as much clarity.  Lots of networking 
>experience
>has shown us that reliable multicasting at large scale is difficult.  However,
>for smaller scale its not so difficult.  It is
>certainly more complex.  Should DTN support 'small-scale' multicast?
>I'm not completely sure, but if the answer is 'no' then we have to do it 
>on top.
>That would amount to a reliable multicast overlay on top of dtn, which is an
>overlay itself [gag], so my inclination would be to embrace multicast at least
>at some point.  However, in order to maintain progress with our
>current direction, I'm willing to forego the mcast part while we get
>fragmentation working properly.  [of course, there's also security to do 
>too :<>].

I'm not too bothered by the difficulty of multicast; if it's needed, and 
it's possible, then we should do it.  Again, though, my concern that it has 
been way too easy to festoon Bundling with cheerful bells and whistles that 
make it fun to write about but difficult to sell to real users, who may not 
need those particular bells and those particular whistles.  The fact that 
we've been able to demonstrate Bundling with a relatively straight face at 
JPL, without even a hint of multicast support, suggests to me that it is 
not a core feature of the protocol.

Scott 

Date: Tue, 06 Apr 2004 12:15:44 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

At 07:30 PM 4/6/2004 +0100, Stephen Farrell wrote:
>Scott Burleigh wrote:
>>At 12:17 PM 4/6/2004 +0100, Stephen Farrell wrote:
>>
>>>>Are you sure this is what you want to say?  It sounds a bit like 
>>>>catechism rather than argument.  We're not talking about "handling 
>>>>higher layer data structures",
>>>
>>>
>>>Yes, we are. If Block ID is anything other than an indicator
>>>of higher layer PDU structure, then its not what you and the
>>>spec said it was. This really is sending the the angle-brackets
>>>in LTP when the higher layer is using XML!
>>
>>No, it isn't.  It is sending some application-specified metadata along 
>>with the data, to enable the destination client service to make use of 
>>the data, and doing so in a way that potentially improves the destination 
>>client service's ability to make use of the data even if part of it is 
>>lost and is pending retransmission.
>
>Quote1:
>         We're not talking about "handling higher layer data structures"
>Quote2:
>         It is sending some application-specified metadata
>
>Don't those contradict one another?

Nope, no more than "sending some application-specified data" contradicts 
Quote1.  All that is happening is packaging and encapsulation.  The 
metadata, like the data, is opaque to LTP.

>>>>>The current scheme also requires the higher layer to know how
>>>>>higher layer PDUs are fragmented into LTP segments, which is,
>>>>>again, a bad thing.
>>>>
>>>>Not at all.  This is precisely what I was explaining it does NOT do.
>>>>Only the implementation of LTP needs to know how client service data is 
>>>>chopped up into LTP segments, and so that is where the decisions on 
>>>>inserting block ID have to be made.
>>>
>>>Then I don't understand how the LTP implementation can ever know
>>>when to include and when not to include the Block ID in a segment.
>>>I really don't.
>>I don't know either, because the answer might vary wildly depending on 
>>the nature of the deployment environment.  Which is why this decision is 
>>identified as an implementation matter.
>
>This is where it gets automagical. Somehow the block ID is or is not
>included. Do you know any algorithm that can do that without application
>layer prompting, and without the application layer being either called
>via some callback, or else told explicitly about LTP fragmentation.

Sure.  Given mean rate of segment loss (from historical statistics, or from 
operational predictions from Somewhere Else) and number of data segments in 
block (computed from block size and maximum data segment size), compute 
expected number of segments lost in the initial transmission of this 
block.  Add 1; the result is B, the number of data segments that you would 
like to include block ID, to minimize the chance of block ID not being 
received in any data segment on initial transmission.  Divide the number of 
data segments in the block by B, yielding N; during initial transmission 
insert block ID into the first data segment of the block and into every Nth 
subsequent data segment.

I don't claim that this is the world's cleverest algorithm for this 
purpose, but it's the sort of thing I can imagine a mission asking 
for.  Anyway, I think it's an existence proof that there is no magic involved.

>>>>>BUT, do you have a concrete example of where this saves the day? If
>>>>>so, then you've a winning argument. But, if not, then I think this
>>>>>feature is just a layering violation pure and simple and shouldn't
>>>>>be kept.
>>>>
>>>>I don't understand what you mean by "saves the day".  It's a means of 
>>>>conveying information that the client service requires, in a way that 
>>>>is as efficient as the implementation chooses to make it.
> >>
>>>What I meant was that I'll shut up if there's an application context
>>>where this mechanism is convincing. For all the applications I can
>>>imagine the higher-layer approach seems better, but then you guys
>>>know more about deep space apps than I do, so I'm asking to be
>>>convinced. Basically, even though its a layering violation, I could
>>>live with that if its a useful enough layering violation:-)
>>I guess it's a layering violation to the same extent that sending file 
>>name along with file content is a layering violation in FTP.
>
>Huh? FTP is an application layer protocol isn't it? So it should handle
>filenames (given what the "F" in FTP stands for). The filename isn't
>automagically sometimes sent and sometimes not and the transport layer
>(TCP) doesn't see the filename as a field. So the FTP "example" has
>nothing in common with this issue. (Except perhaps some CFDP history.)

So you're saying that FTP is never invoked by higher-level services as a 
way to convey data in a network, the way email is (and CFDP is)?  I think 
the parallel is exact.

> > The
>>mechanism is a direct adaptation (a generalization) of the source and 
>>destination filenames sent in the "Metadata" PDU in a CFDP file 
>>transmission.  And you're right, block ID could certainly be sent just 
>>once per LTP block transmission and could even be inserted by the 
>>application at the front of the block content and parsed out by the 
>>application, without LTP ever seeing it at all; in CFDP the Metadata PDU 
>>is sent only once per transaction (unless it gets lost and needs to be 
>>retransmitted), and I'm no FTP expert but I image that filename is 
>>typically sent only once in any FTP file transfer.
>>The reason it is called out separately in the LTP spec and is handled 
>>separately from the block content is that some potential CFDP users have 
>>said they would like the Metadata to be transmitted multiple times per 
>>transaction.
>
>I get the requirement. I cannot see how it can sensibly be
>met at the LTP layer without all sorts of ikky layering
>violations. I can see how to meet the requirement at the
>layer above LTP.
>
>Here's an XML equivalent of what the higher layer should do:
>
>         Bad: <foo> "bar" "baz" </foo>
>         Good: <foo> "bar" </foo> <foo> "baz"</foo>
>
>(no I don't like xml, but it does make for a clear good/bad example)

Not particularly.

The point is that the upper layer protocol should never need to worry its 
little head about this kind of thing.  Conveying metadata along with data, 
in the most effective way it knows how, is a service that LTP provides to 
its user [which happens to be an upper-layer protocol implementation in 
most cases] in the same way that CFDP provides this service to its user 
[which happens to be an autonomous software agent in most cases] and in the 
same way that FTP provides this service to its user [which happens to be an 
FTP client or server program in most cases].

>Its that easy at the higher layer. Its automagical inside the
>LTP layer.

No, it isn't.

Scott 

Date: Tue, 06 Apr 2004 11:45:40 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] more ltp comments
Sender: [email-masked]

At 06:33 PM 4/6/2004 +0100, Stephen Farrell wrote:
>But, since we're repeating ourselves, and as you also suggested,
>maybe we should wait a bit and see if anyone else wants to chime
>in. (If not, I'll toss a coin and let you know what happens:-)

Excellent.

>PS: Meanwhile, I've just noticed that each and every offset and length
>field in an RS is an SDNV, and hence has its own length field requiring an 
>additional byte for each, (assuming offsets & lengths would
>be expected to be >127). So I think that the encoding of RS segments
>isn't actually that parsimonious, which further argues for the
>additional byte required to distinguish complete vs. truncated RS
>segments. (As an aside, you could define a new type "SDNV-16" which
>works like an SDNV but where the MSB being clear means that the
>remainder of the 2-byte-fixed-size field is a value, and where the
>MSB being set means that its handled like a current SDNV. You could
>also have an SDNV-32, etc. and then depending on the likely values,
>using those types can save you some bytes in RS segments and maybe
>elsewhere. Not sure if that'd be worthwhile, was it considered
>already?)

No, it wasn't, and I think it's a terrific idea.

Scott 

From: "Keith Scott" <[email-masked]>
To: <[email-masked]>
Subject: RE: [dtn-interest] fragmentation and erasure coding in Bundling
Date: Tue, 6 Apr 2004 14:35:29 -0400
Organization: The MITRE Corporation
Sender: [email-masked]

All good questions.

The real question boils down to how (and if) to mix 'regular' fragmentation
with FEC, and how to do that in the presence of custody.  In response to one
of your questions below I list a few possible rules for doing this, none of
which, IMHO, require profound architectural changes.
 
I note that we could remove any notion of fragmentation from the bundling
layer and require it to happen in convergence layers.

Other responses inline

		--keith

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Kevin Fall
>Sent: Tuesday, April 06, 2004 12:52 PM
>To: [email-masked]
>Subject: [dtn-interest] fragmentation and erasure coding in Bundling
>
>
>There has been some recent discussion regarding how to implement
>bundle fragmentation, what to do about custody transfer when
>fragments are used, and what happens if we consider using
>Digital Fountain (DF)-like codes in conjunction with fragmentation.
>[There is a set of online codes similar to DF functionality 
>but which are not proprietary].
>Scott has nicely summarized and asked some provocative questions
>regarding this, below...
>
>>
>> From:  Scott Burleigh <[email-masked]>
>> Subject: erasure coding in Bundling
>> Date:  Tue, 06 Apr 2004 08:15:06 PDT
>>
>> One impression I got [...] was this: maybe we don't 
>> all agree that adding erasure coding as an alternative fragmentation 
>> mechanism within bundling itself (as opposed to an 
>end-to-end system above 
>> bundling or a convergence-layer system underneath bundling) would 
>> necessarily have a huge impact on the DTN architecture and 
>the Bundling 
>> protocol spec.  It's just one additional header, after all.
>> 
>> To try to make my point that we are talking about a major, 
>destabilizing 
>> change, I started writing down some of the questions I 
>thought we would 
>> need to answer before issuing the next round of architecture 
>and protocol 
>> spec drafts:

I am somewhat unclear as to why you imply such an urgency to resolving this,
but the questions will need to be answered at some point, and sooner is
better.

>> When Bundling uses DF to fragment a bundle, issuing code 
>blocks, are the 
>> code blocks issued in bundles, or are they issued in some 
>other type of
>> protocol data unit?  If the latter, we've got a profound 
>architectural change.
>
>in bundles, I would think.  We may need to mark them specially (via a
>revision of frag header), but are otherwise semantically the same
>

Concur.

>> 
>> If the code blocks are issued in bundles, are these bundles 
>treated the 
>> same way as all other bundles (except, obviously, for the 
>procedures used 
>> to reconstitute original bundles from them), or are there 
>now two different 
>> classes of bundles that are treated differently by bundle 
>agents?  If the 
>> latter, we've got a profound architectural change that seriously 
>> complicates the protocol.
>
>just re-constitution
>

Treat DF fragments just as we would regular bundles (or regular fragments).

>> 
>> If bundles whose payloads are DF code blocks (rather than 
>conventional 
>> fragments) are treated just like all other bundles, then they must be
>> subject to reactive fragmentation like all other bundles, right?
>
>yes
>
>> If so, 
>> each one has to be uniquely identifiable (to enable conventional
>> reassembly); what uniquely identifying bundle ID extension 
>accomplishes 
>> this?  When a DF code block is reactively fragmented, what do those
>> fragments look like?  Is the key (etc.) stuff of the DF code 
>block carried 
>> only in the first of those fragments?
>
>the simplest version would be to do conventional reactive frag if this
>happens (which would entail creating new frag headers with the
>appropriate info in them as would be normal).  There is a 
>"fancier idea" we've been kicking around about
>actually munging the contents of the codeblock into parts, but this
>is still sort of open.
>

I think the point is that since the (source entity ID, sending timestamp)
would presumably be the same for all DF-encoded fragments of the same bundle
(since this tuple is what uniquely identifies the association among
fragments) we would have to introduce some other field for bundles that were
DF-encoded and then had their DF codeblock (bundles) further fragmented.
The purpose of this field would be to allow the fragments to be correctly
associated before DF decoding takes place.  To be extremely concrete, if two
separate DF codeblocks were fragged into 100-byte chunks, there would be two
bundles with the same (source entity ID, sending timestamp) and fragment
offset 0 length 100.  I think the notion of having the DF fragmentation
process generate lots o' little fragments (~ 40 bytes each) so that they can
be arbitrarily split _without_ the complication Scott envisions (i.e. no
need for an additional identifying extension) is your open issue?  I still
don't like the lots of little codeblocks approach, due to perceived
overhead.

>> 
>> If DF can be used to fragment a bundle, and all bundles are 
>treated the 
>> same, then DF can be used to fragment a conventional 
>fragment, right?  And
>> in fact DF can also be used to fragment a bundle whose 
>payload is a DF code 
>> block, right?
>
>yup, if you really care to do that
>
>> 
>> If the only type of protocol data unit we've got in Bundling 
>is Bundles, 
>> then the only thing you can take custody of is a bundle, 
>yes?  If not, 
>> we've got a profound architectural change: "partial custody 
>transfer", the 
>> ancient "bindling" argument.
>
>Well, I'm not exactly sure what the change is.  If we go
>with the approach that frags are bundles, then 'partial 
>custody' equates
>with 'custody'.  Only the reassembly is a bit different.
>

We have this problem with 'regular' fragments in the following way.  I am
the custodian for bundle X which, several (bundle) hops downstream is
fragmented into bundles X1, X2, X3.  All are marked as custodial, with me as
the stuckee.  I MUST be prepared to deal with getting three separate custody
ACKs, each covering part of the bundle.

>> 
>> If an application requests custodial delivery of an 
>application data unit, 
>> does that QoS propagate to all fragments of the resulting 
>bundle?  If not, 
>> we're not treating all bundles the same; a profound (and 
>complicating) 
>> architectural change.
>
>I assume it propagages, requiring no other change.
>
>> 
>> If custodial delivery propagates to all fragments of the 
>original bundle to 
>> which it was applied, then custodial delivery propagates to 
>fragmentary
>> bundles resulting from DF encoding -- and to the 
>conventional and/or DF 
>> fragments into which those fragments might be divided.  Are custody 
>> transfer procedures the same for those fragments as for the original 
>> bundle?  If not, we're not treating all bundles the same; we have 
>> introduced additional complexity into the protocol.  If so, 
>any custodial 
>> retransmission that applies to DF-based fragments is redundant.
>
>That might change, which I see might be like this.  If you are 
>using an error correcting
>code and you successfully custody xfer some threshold 
>percentage of them to other
>custodians then you assume you have successfully moved custody 
>along.  This
>is different, but I think would lead to little code 
>complexity.  The difference amounts
>to whether you use one ACK or multiple ACKs in order to assume 
>you have done
>your job.
>

I agree that this is a complicated area, but not that this introduces any
architecture-breaking complexity into the protocol.  It might be as simple
as:

1) You SHOULD NOT apply DF-encoding to custodially transmitted bundles,
since it would cause all the DF codeblocks to be custodially delivered which
is silly.
2) If you apply DF-encoding to custodially transmitted bundles, then you
MUST first employ bundle-in-bundle encapsulation (to preserve the current
custodian in the inner bundle) and then apply DF; the DF codeblocks MUST NOT
have custody set.  This leaves the DF-fragmenter as the stuckee until either
the bundle is opportunistically DF-decoded (at which time the decodee or any
downstream node may elect to take custody) or, more probably (at least the
way I usually think about things) until the DF-fragments hit the ultimate
destination.
3a) You must do tunneling as well if you want to DF-encode a fragment (this
is a non-invasive way of getting a separate unique identifier for the DF
codeblock bundles)
3b) We have some rules about which headers appear and are processed in what
order.

>> 
>> What about custody transfer for conventional fragments of DF 
>fragments?  Do 
>> we bother to do it, since it's at cross-purposes with the DF 
>encoding?  If 
>> not, we have introduced another little increment of 
>complexity into the 
>> protocol.
>
>It could be allowed.  It just doesn't necessarily seem to 
>offer profound
>benefits.
>

Presumably a fragment of a single codeblock is useless, and so must be
reunited with its brethren before it can be presented to a DF decoder.  I
think the answer to this is tied up in the above question of what to do
about DF AND regular fragmentation.  It would seem to be a requirement for
the case where some router does DF encoding and ends up with codeblocks that
are too large to transit some downstream region.

>> 
>> If an application requests some other QoS service for an 
>application data 
>> unit, such as reception reporting, does that QoS propagate 
>to all fragments 
>> of the resulting bundle?  If not, we've got a significant 
>architectural chang
>e.
>
>I'm not sure.  It may depend.  I am reminded about ICMP messages for
>fragments.  In that case, there are particular rules that 
>apply to fragments,
>and I would be terribly surprised if we end up going in a 
>similar direction.
>But I also don't think this should pose too much of a problem. 
> Indeed, my
>hunch is that frags would be treated as bundles generally, but in the
>particular e2e ack case we have available you would need the 
>entire thing
>to be at the final dest (which is the case anyhow).
>

Yes, what do we do about that with regular fragmentation?

>> 
>> If reception reporting propagates to all fragments of the 
>original bundle 
>> to which it was applied, then reception reporting propagates 
>to fragmentary 
>> bundles resulting from DF encoding -- and to the 
>conventional and/or DF 
>> fragments into which those fragments might be divided.  This 
>could result 
>> in some pretty baffling and useless reports being passed 
>back to the source 
>> application.  If we don't do this, we're not treating all 
>bundles the same; 
>> we have introduced additional complexity into the protocol.
>
>why would it be baffling?  Also, recall that the reports don't need
>to be sent back to the source.  Although I'm not sure of this, if you
>frag an IP packet with a low ttl and the frags are, say, 
>routed in different
>paths and they expire in-transit... I believe you get an ICMP 
>indication for
>each... but I would have to check that.
>

Yes, what do we do about that with regular fragmentation?

>> 
>> These are the only points I can think of off the top of my 
>head, without 
>> any of the documents in front of me.  If we start down this path in 
>> earnest, of course, we will have to go through the spec and the 
>> architecture draft in detail to see what else must be addressed.
>> 
>> All of which would obviously be worthwhile if erasure coding 
>were a central 
>> and indispensable capability for delay-tolerant networking.  
>It is not.
>>

Neither is fragmentation.

>> Certainly it will be extremely valuable in a number of environments, 
>> possibly a very large number: it's a great way to do 
>multi-path routing, 
>> and it's a great way to do multicast.  But in 18 years of 
>network systems 
>> development at JPL I have never seen an application that needed 
>> multicast.

Multicast is probably as large a driver for the military as small code
footprint is for space missions.  Something like 80% of the Army's traffic
is multicast.  It is an absolute requirement for their environment  They
have lots of 'everybody needs to know this' traffic (like: here's where I
am, don't shoot here), and really low capacity links.

>> I have seen maybe one application that could have used 
>> multi-path routing, to compensate for some deficiencies in network 
>> design.  You don't need multicast when there's only a single 
>destination; 
>> you don't need multi-path when there's only a single path, 
>or when any 
>> single path is sufficient to carry your message.  
>Applications with these 
>> characteristics will be with us for a long time.
>> 

One of the main advantages people tout about SCTP is its ability to do
multi-path message transfer.  SCTP was moved out of sigtrans into the
transport area specifically because people saw use for it as a general
purpose transport protocol for new applications.

>> I do not doubt for an instant that multi-path and multicast 
>are needed for 
>> military applications, especially mobile tactical 
>applications; I don't 
>> doubt for an instant that the Internet needs multicast for 
>information 
>> streaming, nor that it needs multi-path for mobile applications.  We 
>> certainly have got to support this stuff.

Right.  And I believe that we can support them by saying, in the
specification, something like: If you want to do FEC encoding, here's how to
do it.  Here are situations where we know it will be silly, and here are
some other (informative) guidelines.  We do NOT have to require that every
implementation provide DF-decoding services.

>> What we don't need to do, though, is make it a cornerstone of 
>> delay-tolerant networking, any more than we need to make 
>ephemerides-aware 
>> forwarding a cornerstone of delay-tolerant networking.

The concept of 'scheduled connectivity' (in addition to predicted and
opportunistic) is fundamental to DTN.  It doesn't matter whether that
schedule is dictated by physics or military doctrine.

>>  The 
>additional 
>> complexity imposed by these devices is amply justified in 
>the environments 
>> where they are needed, but not in the core of bundling that 
>everybody has 
>> to work with.  Let's implement them in convergence layer 
>adapters where 
>> they are required, rather than jam them down the throats of 
>developers and 
>> users who do not want or need them.  Let's be modular.  
>Let's try to avoid 
>> making CFDP's mistakes all over again.
>> 

While possibly powerful tools within convergence layers, these tools are
much more powerful if they can be applied to bundle transfer as a whole
rather than forcing all traffic through a single regional exit point.  By
forcing this functionality (which includes regular fragmentation, BTW) into
convergence layers, we LOSE the ability to exploit multiple paths through
the network.  This is fine for deep-space communications, where there is
exactly one path, but that (hopefully) isn't going to be everyone's model.

>> Scott
>> 
>
>Well, hmm.  So this is the realm of opinion I guess.  I believe that
>there are two primary things dtn wishes to accomplish:  handle 
>disconnection
>reasonably well, and handle interoperability across very heterogeneous
>networks.  To handle disconnection we have the concepts of contacts
>and an interesting routing problem becomes to "fill" them.  In a broad
>range of cases there are multiple paths available (because of 
>the "new ability"
>to handle heterogeneous devices [think: 'if I have any 
>connection possible I can
>make use of it with DTN']) and in some of those simultaneous 
>use will be
>desirable.  Fragmentation is for two things:  1> what to do to 
>large messages
>so you can send them over multiple paths, perhaps 
>simultaneously, and 2> what
>to do with a large message while, during a transfer at a link, 
>you encouter
>an interruption but you still want to make use of that data 
>that did arrive.
>#2 is the 'reactive fragmentation' concept, and it is a 
>performance optimization.
>If the "main routing" is functioning properly and there are no 
>unexpected interruptions
>you should never see it happening.
>
>I cannot address multicast with as much clarity.  Lots of 
>networking experience
>has shown us that reliable multicasting at large scale is 
>difficult.  However,
>for smaller scale its not so difficult.  It is
>certainly more complex.  Should DTN support 'small-scale' multicast?
>I'm not completely sure, but if the answer is 'no' then we 
>have to do it on top.
>That would amount to a reliable multicast overlay on top of 
>dtn, which is an
>overlay itself [gag], so my inclination would be to embrace 
>multicast at least
>at some point.  However, in order to maintain progress with our
>current direction, I'm willing to forego the mcast part while we get
>fragmentation working properly.  [of course, there's also 
>security to do too :<>].
>
>- K
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Tue, 06 Apr 2004 19:30:30 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

Blow-by-blow responses below...

Scott Burleigh wrote:
> At 12:17 PM 4/6/2004 +0100, Stephen Farrell wrote:
> 
>>> Are you sure this is what you want to say?  It sounds a bit like 
>>> catechism rather than argument.  We're not talking about "handling 
>>> higher layer data structures",
>>
>>
>> Yes, we are. If Block ID is anything other than an indicator
>> of higher layer PDU structure, then its not what you and the
>> spec said it was. This really is sending the the angle-brackets
>> in LTP when the higher layer is using XML!
> 
> 
> No, it isn't.  It is sending some application-specified metadata along 
> with the data, to enable the destination client service to make use of 
> the data, and doing so in a way that potentially improves the 
> destination client service's ability to make use of the data even if 
> part of it is lost and is pending retransmission.

Quote1:
	We're not talking about "handling higher layer data structures"
Quote2:
	It is sending some application-specified metadata

Don't those contradict one another?

To go back to flippant mode: Ok, so its not the angle brackets,
its the RDF description that'll be occasionally automagically
inserted into the datastream by a lower layer (LTP)!!!

>>>> Also, the LTP implementation can't know when to include/omit
>>>> the block ID without higher layer prompting, so there has
>>>> to be higher layer code which knows this LTP "feature" so why
>>>> not have different higher layer code that achieves the effect
>>>> without requiring the lower layer's co-operation. (E.g. repeating
>>>> some context information occasionally within the data.)
>>>
>>> The spec says "The mechanism by which the data segments that will 
>>> carry block ID are selected is a local implementation matter."  If 
>>> you want the upper-layer protocol to participate in these kinds of 
>>> decisions, you can provide an implementation-specific mechanism to 
>>> enable that behavior -- or you can do it another way.
>>
>>
>> That's not the point. Having the upper layer involved means that
>> you probably have a better solution - letting the upper layer
>> handle the repitition of data/structure-indicators itself.
> 
> Except I would *not* involve the upper-layer protocol in these 
> decisions, because LTP segmentation should not be exposed to the upper 
> layer protocol.

Again. I'm lost as to how this can work, but see the next point.

>>>> The current scheme also requires the higher layer to know how
>>>> higher layer PDUs are fragmented into LTP segments, which is,
>>>> again, a bad thing.
>>>
>>>
>>> Not at all.  This is precisely what I was explaining it does NOT do.
>>> Only the implementation of LTP needs to know how client service data 
>>> is chopped up into LTP segments, and so that is where the decisions 
>>> on inserting block ID have to be made.
>>
>>
>> Then I don't understand how the LTP implementation can ever know
>> when to include and when not to include the Block ID in a segment.
>> I really don't.
> 
> I don't know either, because the answer might vary wildly depending on 
> the nature of the deployment environment.  Which is why this decision is 
> identified as an implementation matter.

This is where it gets automagical. Somehow the block ID is or is not
included. Do you know any algorithm that can do that without application
layer prompting, and without the application layer being either called
via some callback, or else told explicitly about LTP fragmentation. In
the absence of the demonstration of the existence of a sensible
algorithm, I think this has to be dropped.

>>>> BUT, do you have a concrete example of where this saves the day? If
>>>> so, then you've a winning argument. But, if not, then I think this
>>>> feature is just a layering violation pure and simple and shouldn't
>>>> be kept.
>>>
>>> I don't understand what you mean by "saves the day".  It's a means of 
>>> conveying information that the client service requires, in a way that 
>>> is as efficient as the implementation chooses to make it.
 >>
>> What I meant was that I'll shut up if there's an application context
>> where this mechanism is convincing. For all the applications I can
>> imagine the higher-layer approach seems better, but then you guys
>> know more about deep space apps than I do, so I'm asking to be
>> convinced. Basically, even though its a layering violation, I could
>> live with that if its a useful enough layering violation:-)
> 
> I guess it's a layering violation to the same extent that sending file 
> name along with file content is a layering violation in FTP.  

Huh? FTP is an application layer protocol isn't it? So it should handle
filenames (given what the "F" in FTP stands for). The filename isn't
automagically sometimes sent and sometimes not and the transport layer
(TCP) doesn't see the filename as a field. So the FTP "example" has
nothing in common with this issue. (Except perhaps some CFDP history.)

 > The
> mechanism is a direct adaptation (a generalization) of the source and 
> destination filenames sent in the "Metadata" PDU in a CFDP file 
> transmission.  And you're right, block ID could certainly be sent just 
> once per LTP block transmission and could even be inserted by the 
> application at the front of the block content and parsed out by the 
> application, without LTP ever seeing it at all; in CFDP the Metadata PDU 
> is sent only once per transaction (unless it gets lost and needs to be 
> retransmitted), and I'm no FTP expert but I image that filename is 
> typically sent only once in any FTP file transfer.
> 
> The reason it is called out separately in the LTP spec and is handled 
> separately from the block content is that some potential CFDP users have 
> said they would like the Metadata to be transmitted multiple times per 
> transaction.  

I get the requirement. I cannot see how it can sensibly be
met at the LTP layer without all sorts of ikky layering
violations. I can see how to meet the requirement at the
layer above LTP.

Here's an XML equivalent of what the higher layer should do:

	Bad: <foo> "bar" "baz" </foo>
	Good: <foo> "bar" </foo> <foo> "baz"</foo>

(no I don't like xml, but it does make for a clear good/bad example)

Its that easy at the higher layer. Its automagical inside the
LTP layer.

> Certainly if LTP is used only underneath Bundling the utility of sending 
> block ID more than once is pretty close to zero: none of the segments of 
> the block are of any use to Bundling if the first segment never 
> arrives.  So really this feature of the LTP design is intended to make 
> it potentially more useful in other kinds of stacks.  

Doesn't sound like a compelling use case!

 > Maybe we should not bother about it[...]

I'm with you there!

Stephen.

Date: Tue, 06 Apr 2004 10:59:27 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

At 12:17 PM 4/6/2004 +0100, Stephen Farrell wrote:

>>Are you sure this is what you want to say?  It sounds a bit like 
>>catechism rather than argument.  We're not talking about "handling higher 
>>layer data structures",
>
>Yes, we are. If Block ID is anything other than an indicator
>of higher layer PDU structure, then its not what you and the
>spec said it was. This really is sending the the angle-brackets
>in LTP when the higher layer is using XML!

No, it isn't.  It is sending some application-specified metadata along with 
the data, to enable the destination client service to make use of the data, 
and doing so in a way that potentially improves the destination client 
service's ability to make use of the data even if part of it is lost and is 
pending retransmission.

>>>Also, the LTP implementation can't know when to include/omit
>>>the block ID without higher layer prompting, so there has
>>>to be higher layer code which knows this LTP "feature" so why
>>>not have different higher layer code that achieves the effect
>>>without requiring the lower layer's co-operation. (E.g. repeating
>>>some context information occasionally within the data.)
>>The spec says "The mechanism by which the data segments that will carry 
>>block ID are selected is a local implementation matter."  If you want the 
>>upper-layer protocol to participate in these kinds of decisions, you can 
>>provide an implementation-specific mechanism to enable that behavior -- 
>>or you can do it another way.
>
>That's not the point. Having the upper layer involved means that
>you probably have a better solution - letting the upper layer
>handle the repitition of data/structure-indicators itself.

Except I would *not* involve the upper-layer protocol in these decisions, 
because LTP segmentation should not be exposed to the upper layer protocol.

>>>The current scheme also requires the higher layer to know how
>>>higher layer PDUs are fragmented into LTP segments, which is,
>>>again, a bad thing.
>>
>>Not at all.  This is precisely what I was explaining it does NOT do.
>>Only the implementation of LTP needs to know how client service data is 
>>chopped up into LTP segments, and so that is where the decisions on 
>>inserting block ID have to be made.
>
>Then I don't understand how the LTP implementation can ever know
>when to include and when not to include the Block ID in a segment.
>I really don't.

I don't know either, because the answer might vary wildly depending on the 
nature of the deployment environment.  Which is why this decision is 
identified as an implementation matter.

>>>BUT, do you have a concrete example of where this saves the day? If
>>>so, then you've a winning argument. But, if not, then I think this
>>>feature is just a layering violation pure and simple and shouldn't
>>>be kept.
>>I don't understand what you mean by "saves the day".  It's a means of 
>>conveying information that the client service requires, in a way that is 
>>as efficient as the implementation chooses to make it.
>
>What I meant was that I'll shut up if there's an application context
>where this mechanism is convincing. For all the applications I can
>imagine the higher-layer approach seems better, but then you guys
>know more about deep space apps than I do, so I'm asking to be
>convinced. Basically, even though its a layering violation, I could
>live with that if its a useful enough layering violation:-)

I guess it's a layering violation to the same extent that sending file name 
along with file content is a layering violation in FTP.  The mechanism is a 
direct adaptation (a generalization) of the source and destination 
filenames sent in the "Metadata" PDU in a CFDP file transmission.  And 
you're right, block ID could certainly be sent just once per LTP block 
transmission and could even be inserted by the application at the front of 
the block content and parsed out by the application, without LTP ever 
seeing it at all; in CFDP the Metadata PDU is sent only once per 
transaction (unless it gets lost and needs to be retransmitted), and I'm no 
FTP expert but I image that filename is typically sent only once in any FTP 
file transfer.

The reason it is called out separately in the LTP spec and is handled 
separately from the block content is that some potential CFDP users have 
said they would like the Metadata to be transmitted multiple times per 
transaction.  In unreliable mode the advantage is fairly clear: if the 
metadata (in LTP's case, the block ID) is transmitted only once per block, 
and you lose the segment that contains the metadata, you can't use any of 
the other segments.  In reliable mode the advantage is less obvious, 
because eventually the metadata is bound to get retransmitted and you will 
receive it.  But sending the metadata multiple times reduces the chance 
that you'll have to wait for a retransmission before you can use any of the 
received segments of the block data, so it potentially reduces the latency 
of at least partial data delivery.

Certainly if LTP is used only underneath Bundling the utility of sending 
block ID more than once is pretty close to zero: none of the segments of 
the block are of any use to Bundling if the first segment never 
arrives.  So really this feature of the LTP design is intended to make it 
potentially more useful in other kinds of stacks.  Maybe we should not 
bother about it.  But anyway, that is the rationale.

Scott 

Date: Tue, 06 Apr 2004 18:33:43 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] more ltp comments
Sender: [email-masked]

Scott Burleigh wrote:
> At 05:45 PM 4/6/2004 +0100, Stephen Farrell wrote:
> 
>>> Okay, I think there is a general issue here that needs to be resolved.
>>> The general issue is what level of service LTP can expect from the 
>>> underlying link layer -- or, put another way, what level of service 
>>> LTP may require of the underlying link layer -- or, put yet another 
>>> way, which underlying link protocols LTP may be operated over.
>>> At one extreme -- which is the position from which the LTP draft is 
>>> currently written -- LTP requires that the link layer protocol 
>>> deliver the complete payload (in this case, a single LTP segment) of 
>>> a single, integral link-layer protocol data unit, in which there are 
>>> no known bit errors, and note the length of that delivered payload.  
>>> This has the disadvantage of limiting LTP to operation over those 
>>> link layer protocols that can offer this level of service; moreover, 
>>> any implementation errors in those protocols will result in LTP 
>>> operational errors.  The advantage is that LTP itself can be somewhat 
>>> smaller, simpler, and more laconic: there is no need to carry in the 
>>> segment header a segment content length or a CRC, for example.
>>> Alternatively, LTP could require far less of the link layer protocol 
>>> (that is, trust it far less).  This would have the advantage of 
>>> enabling LTP to operate over a wider array of link layer protocols 
>>> and would reduce its vulnerability to implementation errors in those 
>>> protocols.
>>> The disadvantage is that LTP would need to be somewhat more complex 
>>> and inevitably somewhat larger, and more information would need to be 
>>> carried in the segment header.
>>> I'm sure it's clear which side of this question I come down on :-), 
>>> and I think that position is justified by the quality and capability 
>>> of the space-qualified link layer protocols LTP is designed to run 
>>> over in the Interplanetary Internet.  But I certainly agree that this 
>>> design choice might limit the usability of LTP in some terrestrial 
>>> environments.
>>> Anybody out there have any thoughts on this?
>>
>>
>> I don't see any need to resort to general questions about
>> link layers to resolve this issue (and fwiw, I'd be with you
>> on the general question here, were it relevant, which it isn't).
>>
>> This is a much simpler discussion:
>>
>> It is IMO unreasonable to define LTP packets where you can't tell
>> just by looking whether the packet is complete or truncated.
> 
> 
> That's a reasonable opinion, but if you *know* that the packet is 
> complete -- because you trust the link layer protocol to deliver only 
> complete packets -- then it is moot: there's no need to tell just by 
> looking, because you already know.  The answer to the general question 
> subsumes this discussion, and potentially a lot of others.  That is why 
> it is relevant, and why I bring it up.

It is true that some answers (of which there are more than two)
to your general question subsume this discussion. It is also true
that not all do. It is further true that at least the "easier to
formally analyse" argument, if true, is not affected by the
general question posed. Therefore the issue is not moot, and
should IMO be decided on its merits, without reference to the
general question.

But, since we're repeating ourselves, and as you also suggested,
maybe we should wait a bit and see if anyone else wants to chime
in. (If not, I'll toss a coin and let you know what happens:-)

Stephen.

PS: Meanwhile, I've just noticed that each and every offset and length
field in an RS is an SDNV, and hence has its own length field requiring 
an additional byte for each, (assuming offsets & lengths would
be expected to be >127). So I think that the encoding of RS segments
isn't actually that parsimonious, which further argues for the
additional byte required to distinguish complete vs. truncated RS
segments. (As an aside, you could define a new type "SDNV-16" which
works like an SDNV but where the MSB being clear means that the
remainder of the 2-byte-fixed-size field is a value, and where the
MSB being set means that its handled like a current SDNV. You could
also have an SDNV-32, etc. and then depending on the likely values,
using those types can save you some bytes in RS segments and maybe
elsewhere. Not sure if that'd be worthwhile, was it considered
already?)

Date: Tue, 06 Apr 2004 10:02:00 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] more ltp comments
Sender: [email-masked]

At 05:45 PM 4/6/2004 +0100, Stephen Farrell wrote:
>>Okay, I think there is a general issue here that needs to be resolved.
>>The general issue is what level of service LTP can expect from the 
>>underlying link layer -- or, put another way, what level of service LTP 
>>may require of the underlying link layer -- or, put yet another way, 
>>which underlying link protocols LTP may be operated over.
>>At one extreme -- which is the position from which the LTP draft is 
>>currently written -- LTP requires that the link layer protocol deliver 
>>the complete payload (in this case, a single LTP segment) of a single, 
>>integral link-layer protocol data unit, in which there are no known bit 
>>errors, and note the length of that delivered payload.  This has the 
>>disadvantage of limiting LTP to operation over those link layer protocols 
>>that can offer this level of service; moreover, any implementation errors 
>>in those protocols will result in LTP operational errors.  The advantage 
>>is that LTP itself can be somewhat smaller, simpler, and more laconic: 
>>there is no need to carry in the segment header a segment content length 
>>or a CRC, for example.
>>Alternatively, LTP could require far less of the link layer protocol 
>>(that is, trust it far less).  This would have the advantage of enabling 
>>LTP to operate over a wider array of link layer protocols and would 
>>reduce its vulnerability to implementation errors in those protocols.
>>The disadvantage is that LTP would need to be somewhat more complex and 
>>inevitably somewhat larger, and more information would need to be carried 
>>in the segment header.
>>I'm sure it's clear which side of this question I come down on :-), and I 
>>think that position is justified by the quality and capability of the 
>>space-qualified link layer protocols LTP is designed to run over in the 
>>Interplanetary Internet.  But I certainly agree that this design choice 
>>might limit the usability of LTP in some terrestrial environments.
>>Anybody out there have any thoughts on this?
>
>I don't see any need to resort to general questions about
>link layers to resolve this issue (and fwiw, I'd be with you
>on the general question here, were it relevant, which it isn't).
>
>This is a much simpler discussion:
>
>It is IMO unreasonable to define LTP packets where you can't tell
>just by looking whether the packet is complete or truncated.

That's a reasonable opinion, but if you *know* that the packet is complete 
-- because you trust the link layer protocol to deliver only complete 
packets -- then it is moot: there's no need to tell just by looking, 
because you already know.  The answer to the general question subsumes this 
discussion, and potentially a lot of others.  That is why it is relevant, 
and why I bring it up.

Scott 

To: [email-masked]
Date: Tue, 06 Apr 2004 09:51:31 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] fragmentation and erasure coding in Bundling
Sender: [email-masked]

There has been some recent discussion regarding how to implement
bundle fragmentation, what to do about custody transfer when
fragments are used, and what happens if we consider using
Digital Fountain (DF)-like codes in conjunction with fragmentation.
[There is a set of online codes similar to DF functionality but which are not proprietary].
Scott has nicely summarized and asked some provocative questions
regarding this, below...

>
> From:  Scott Burleigh <[email-masked]>
> Subject: erasure coding in Bundling
> Date:  Tue, 06 Apr 2004 08:15:06 PDT
>
> One impression I got [...] was this: maybe we don't 
> all agree that adding erasure coding as an alternative fragmentation 
> mechanism within bundling itself (as opposed to an end-to-end system above 
> bundling or a convergence-layer system underneath bundling) would 
> necessarily have a huge impact on the DTN architecture and the Bundling 
> protocol spec.  It's just one additional header, after all.
> 
> To try to make my point that we are talking about a major, destabilizing 
> change, I started writing down some of the questions I thought we would 
> need to answer before issuing the next round of architecture and protocol 
> spec drafts:
> 
> When Bundling uses DF to fragment a bundle, issuing code blocks, are the 
> code blocks issued in bundles, or are they issued in some other type of
> protocol data unit?  If the latter, we've got a profound architectural change.

in bundles, I would think.  We may need to mark them specially (via a
revision of frag header), but are otherwise semantically the same

> 
> If the code blocks are issued in bundles, are these bundles treated the 
> same way as all other bundles (except, obviously, for the procedures used 
> to reconstitute original bundles from them), or are there now two different 
> classes of bundles that are treated differently by bundle agents?  If the 
> latter, we've got a profound architectural change that seriously 
> complicates the protocol.

just re-constitution

> 
> If bundles whose payloads are DF code blocks (rather than conventional 
> fragments) are treated just like all other bundles, then they must be
> subject to reactive fragmentation like all other bundles, right?

yes

> If so, 
> each one has to be uniquely identifiable (to enable conventional
> reassembly); what uniquely identifying bundle ID extension accomplishes 
> this?  When a DF code block is reactively fragmented, what do those
> fragments look like?  Is the key (etc.) stuff of the DF code block carried 
> only in the first of those fragments?

the simplest version would be to do conventional reactive frag if this
happens (which would entail creating new frag headers with the
appropriate info in them as would be normal).  There is a "fancier idea" we've been kicking around about
actually munging the contents of the codeblock into parts, but this
is still sort of open.

> 
> If DF can be used to fragment a bundle, and all bundles are treated the 
> same, then DF can be used to fragment a conventional fragment, right?  And
> in fact DF can also be used to fragment a bundle whose payload is a DF code 
> block, right?

yup, if you really care to do that

> 
> If the only type of protocol data unit we've got in Bundling is Bundles, 
> then the only thing you can take custody of is a bundle, yes?  If not, 
> we've got a profound architectural change: "partial custody transfer", the 
> ancient "bindling" argument.

Well, I'm not exactly sure what the change is.  If we go
with the approach that frags are bundles, then 'partial custody' equates
with 'custody'.  Only the reassembly is a bit different.

> 
> If an application requests custodial delivery of an application data unit, 
> does that QoS propagate to all fragments of the resulting bundle?  If not, 
> we're not treating all bundles the same; a profound (and complicating) 
> architectural change.

I assume it propagages, requiring no other change.

> 
> If custodial delivery propagates to all fragments of the original bundle to 
> which it was applied, then custodial delivery propagates to fragmentary
> bundles resulting from DF encoding -- and to the conventional and/or DF 
> fragments into which those fragments might be divided.  Are custody 
> transfer procedures the same for those fragments as for the original 
> bundle?  If not, we're not treating all bundles the same; we have 
> introduced additional complexity into the protocol.  If so, any custodial 
> retransmission that applies to DF-based fragments is redundant.

That might change, which I see might be like this.  If you are using an error correcting
code and you successfully custody xfer some threshold percentage of them to other
custodians then you assume you have successfully moved custody along.  This
is different, but I think would lead to little code complexity.  The difference amounts
to whether you use one ACK or multiple ACKs in order to assume you have done
your job.

> 
> What about custody transfer for conventional fragments of DF fragments?  Do 
> we bother to do it, since it's at cross-purposes with the DF encoding?  If 
> not, we have introduced another little increment of complexity into the 
> protocol.

It could be allowed.  It just doesn't necessarily seem to offer profound
benefits.

> 
> If an application requests some other QoS service for an application data 
> unit, such as reception reporting, does that QoS propagate to all fragments 
> of the resulting bundle?  If not, we've got a significant architectural chang
e.

I'm not sure.  It may depend.  I am reminded about ICMP messages for
fragments.  In that case, there are particular rules that apply to fragments,
and I would be terribly surprised if we end up going in a similar direction.
But I also don't think this should pose too much of a problem.  Indeed, my
hunch is that frags would be treated as bundles generally, but in the
particular e2e ack case we have available you would need the entire thing
to be at the final dest (which is the case anyhow).

> 
> If reception reporting propagates to all fragments of the original bundle 
> to which it was applied, then reception reporting propagates to fragmentary 
> bundles resulting from DF encoding -- and to the conventional and/or DF 
> fragments into which those fragments might be divided.  This could result 
> in some pretty baffling and useless reports being passed back to the source 
> application.  If we don't do this, we're not treating all bundles the same; 
> we have introduced additional complexity into the protocol.

why would it be baffling?  Also, recall that the reports don't need
to be sent back to the source.  Although I'm not sure of this, if you
frag an IP packet with a low ttl and the frags are, say, routed in different
paths and they expire in-transit... I believe you get an ICMP indication for
each... but I would have to check that.

> 
> These are the only points I can think of off the top of my head, without 
> any of the documents in front of me.  If we start down this path in 
> earnest, of course, we will have to go through the spec and the 
> architecture draft in detail to see what else must be addressed.
> 
> All of which would obviously be worthwhile if erasure coding were a central 
> and indispensable capability for delay-tolerant networking.  It is not.
> 
> Certainly it will be extremely valuable in a number of environments, 
> possibly a very large number: it's a great way to do multi-path routing, 
> and it's a great way to do multicast.  But in 18 years of network systems 
> development at JPL I have never seen an application that needed 
> multicast.  I have seen maybe one application that could have used 
> multi-path routing, to compensate for some deficiencies in network 
> design.  You don't need multicast when there's only a single destination; 
> you don't need multi-path when there's only a single path, or when any 
> single path is sufficient to carry your message.  Applications with these 
> characteristics will be with us for a long time.
> 
> I do not doubt for an instant that multi-path and multicast are needed for 
> military applications, especially mobile tactical applications; I don't 
> doubt for an instant that the Internet needs multicast for information 
> streaming, nor that it needs multi-path for mobile applications.  We 
> certainly have got to support this stuff.
> 
> What we don't need to do, though, is make it a cornerstone of 
> delay-tolerant networking, any more than we need to make ephemerides-aware 
> forwarding a cornerstone of delay-tolerant networking.  The additional 
> complexity imposed by these devices is amply justified in the environments 
> where they are needed, but not in the core of bundling that everybody has 
> to work with.  Let's implement them in convergence layer adapters where 
> they are required, rather than jam them down the throats of developers and 
> users who do not want or need them.  Let's be modular.  Let's try to avoid 
> making CFDP's mistakes all over again.
> 
> Scott
> 

Well, hmm.  So this is the realm of opinion I guess.  I believe that
there are two primary things dtn wishes to accomplish:  handle disconnection
reasonably well, and handle interoperability across very heterogeneous
networks.  To handle disconnection we have the concepts of contacts
and an interesting routing problem becomes to "fill" them.  In a broad
range of cases there are multiple paths available (because of the "new ability"
to handle heterogeneous devices [think: 'if I have any connection possible I can
make use of it with DTN']) and in some of those simultaneous use will be
desirable.  Fragmentation is for two things:  1> what to do to large messages
so you can send them over multiple paths, perhaps simultaneously, and 2> what
to do with a large message while, during a transfer at a link, you encouter
an interruption but you still want to make use of that data that did arrive.
#2 is the 'reactive fragmentation' concept, and it is a performance optimization.
If the "main routing" is functioning properly and there are no unexpected interruptions
you should never see it happening.

I cannot address multicast with as much clarity.  Lots of networking experience
has shown us that reliable multicasting at large scale is difficult.  However,
for smaller scale its not so difficult.  It is
certainly more complex.  Should DTN support 'small-scale' multicast?
I'm not completely sure, but if the answer is 'no' then we have to do it on top.
That would amount to a reliable multicast overlay on top of dtn, which is an
overlay itself [gag], so my inclination would be to embrace multicast at least
at some point.  However, in order to maintain progress with our
current direction, I'm willing to forego the mcast part while we get
fragmentation working properly.  [of course, there's also security to do too :<>].

- K

Date: Tue, 06 Apr 2004 17:45:26 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] more ltp comments
Sender: [email-masked]

Go right to the bottom!

>>>>>> 6. How do I spot the end of a report segment? I think there's a 
>>>>>> missing
>>>>>> counter or overall length somewhere since a report segment can have
>>>>>> any number of offset/length pairs. Maybe I'm just missing something?
>>>>>> (My choice would be to change so that the header contains an overall
>>>>>> length field, but a "number of offset/length pairs" field in the
>>>>>> report segment would also do.)
>>>>>
>>>>>
>>>>> The underlying link layer should give you the length of each 
>>>>> segment it delivers to LTP.  (I suspect this requirement imposed on 
>>>>> the underlying link protocol isn't stated explicitly anywhere, and 
>>>>> it should be.)
>>>>
>>>>
>>>>
>>>> I think that's a bad assumption/requirement. Even if a lower layer
>>>> does only present the LTP implementation with what it thinks are
>>>> "full" blocks, there are still potential cases of lower layer
>>>> fragmentation where the "full" lower layer block that goes missing
>>>> is exactly an offset/length pair from an RS. Building Murphy's
>>>> law into a spec in this way seems like a bad idea.
>>>>
>>>> I'm sure there's some networking wisdom somewhere that says that you
>>>> shouldn't define PDUs at level N, s.t. you can't tell at level N
>>>> whether you've got a complete PDU or not. Even if there weren't
>>>> I'd guess that such a "non-determinstic" PDU would be the last thing
>>>> to use when you're handling/reporting errors.
>>>
>>>
>>> All we're talking about is having the link layer protocol deliver the 
>>> complete payload (in this case, a single LTP segment) of a single, 
>>> integral link-layer protocol data unit, in which there are no known 
>>> bit errors, and noting the length of that delivered payload.  I think 
>>> this is just standard service definition.  I don't know of any 
>>> link-layer frame definition that can't tell you the length of the 
>>> upper-layer protocol data payload contained in each frame: either 
>>> that length is carried explicitly in the frame or else the data 
>>> length can be easily inferred because the frame length and frame 
>>> header size are both fixed.
>>> Certainly this is no problem for the CCSDS protocols (telemetry, 
>>> telecommand, AOS) that LTP is designed to run over; Ethernet frames 
>>> carry data length.  What is the issue here?
>>
>>
>> The issue is that "having the link layer delver the complete payload"
>> is not in general going to work. I believe IP/ATM has, and remember
>> IP/X.25 having, exactly this issue where fragmentation does occur
>> "lower" down and the path MTU is very hard to get right. I have
>> seen this happen with Kerberos/UDP/X.25, where the Kerberos codec
>> caught the fragmentation after the Kerberos comms layer missed
>> it - early krbv5 code assumed that all Kerberos AS_REQ messages
>> would fit in a single UDP packet and that there would be no lower
>> layer fragmentation, and hence that a single recvfrom() would be
>> enough for an entire AS_REQ. It wasn't.
>>
>> It may not be common, but it does exist as a corner case, so
>> not including the number of offset/length pairs in an RS (or
>> equivalent) seems to me very shortsighted.
>>
>> Also, in a deep-space context, if the comms go down s.t. an RS is
>> truncated in just this way, are you telling me that there's no-one
>> who'd want to use the bits that arrived already? (Such a change of
>> attitude between link and network layers:-) If they did use those
>> bits then they'd not know whether they've a full or truncated RS
>> and the protocol state machines of the peers are now out of whack
>> in an unexpected manner.
>>
>> Lastly it seems like quite a bad idea from the p-o-v of analysing
>> LTP - presumably a formaly analysis would be simplified if all
>> LTP PDUs were actually self-describing in the fairly minimal
>> sense of allowing detection of PDU truncation.
> 
> 
> Okay, I think there is a general issue here that needs to be resolved.  
> The general issue is what level of service LTP can expect from the 
> underlying link layer -- or, put another way, what level of service LTP 
> may require of the underlying link layer -- or, put yet another way, 
> which underlying link protocols LTP may be operated over.
> 
> At one extreme -- which is the position from which the LTP draft is 
> currently written -- LTP requires that the link layer protocol deliver 
> the complete payload (in this case, a single LTP segment) of a single, 
> integral link-layer protocol data unit, in which there are no known bit 
> errors, and note the length of that delivered payload.  This has the 
> disadvantage of limiting LTP to operation over those link layer 
> protocols that can offer this level of service; moreover, any 
> implementation errors in those protocols will result in LTP operational 
> errors.  The advantage is that LTP itself can be somewhat smaller, 
> simpler, and more laconic: there is no need to carry in the segment 
> header a segment content length or a CRC, for example.
> 
> Alternatively, LTP could require far less of the link layer protocol 
> (that is, trust it far less).  This would have the advantage of enabling 
> LTP to operate over a wider array of link layer protocols and would 
> reduce its vulnerability to implementation errors in those protocols.  
> The disadvantage is that LTP would need to be somewhat more complex and 
> inevitably somewhat larger, and more information would need to be 
> carried in the segment header.
> 
> I'm sure it's clear which side of this question I come down on :-), and 
> I think that position is justified by the quality and capability of the 
> space-qualified link layer protocols LTP is designed to run over in the 
> Interplanetary Internet.  But I certainly agree that this design choice 
> might limit the usability of LTP in some terrestrial environments.  
> Anybody out there have any thoughts on this?

I don't see any need to resort to general questions about
link layers to resolve this issue (and fwiw, I'd be with you
on the general question here, were it relevant, which it isn't).

This is a much simpler discussion:

It is IMO unreasonable to define LTP packets where you can't tell
just by looking whether the packet is complete or truncated. The
"price" for fixing this is a single byte in each RS segment; that
byte containing the number of offset/length pairs with 255 being a
fine maximum I'd imagine (more than that => send >1 RS segment).

So: no need for networking philosophy here, just let's include
that length field and move on!

Stephen.

Date: Tue, 06 Apr 2004 09:11:39 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] more ltp comments
Sender: [email-masked]

At 12:07 PM 4/6/2004 +0100, Stephen Farrell wrote:

>Scott Burleigh wrote:
>>At 02:28 PM 4/5/2004 +0100, Stephen Farrell wrote:
>>
>>>>>         - checkpoint serial number (csn) is therefore a counter
>
>I'll come back to this if I still think the same when I've
>written code, but I should admit that you've made a reasonable
>case that csn's may well be worthwhile. (Not too grudging an
>admission I hope:-)

Hey, I'll take what I can get.

>>>>>6. How do I spot the end of a report segment? I think there's a missing
>>>>>counter or overall length somewhere since a report segment can have
>>>>>any number of offset/length pairs. Maybe I'm just missing something?
>>>>>(My choice would be to change so that the header contains an overall
>>>>>length field, but a "number of offset/length pairs" field in the
>>>>>report segment would also do.)
>>>>
>>>>The underlying link layer should give you the length of each segment it 
>>>>delivers to LTP.  (I suspect this requirement imposed on the underlying 
>>>>link protocol isn't stated explicitly anywhere, and it should be.)
>>>
>>>
>>>I think that's a bad assumption/requirement. Even if a lower layer
>>>does only present the LTP implementation with what it thinks are
>>>"full" blocks, there are still potential cases of lower layer
>>>fragmentation where the "full" lower layer block that goes missing
>>>is exactly an offset/length pair from an RS. Building Murphy's
>>>law into a spec in this way seems like a bad idea.
>>>
>>>I'm sure there's some networking wisdom somewhere that says that you
>>>shouldn't define PDUs at level N, s.t. you can't tell at level N
>>>whether you've got a complete PDU or not. Even if there weren't
>>>I'd guess that such a "non-determinstic" PDU would be the last thing
>>>to use when you're handling/reporting errors.
>>
>>All we're talking about is having the link layer protocol deliver the 
>>complete payload (in this case, a single LTP segment) of a single, 
>>integral link-layer protocol data unit, in which there are no known bit 
>>errors, and noting the length of that delivered payload.  I think this is 
>>just standard service definition.  I don't know of any link-layer frame 
>>definition that can't tell you the length of the upper-layer protocol 
>>data payload contained in each frame: either that length is carried 
>>explicitly in the frame or else the data length can be easily inferred 
>>because the frame length and frame header size are both fixed.
>>Certainly this is no problem for the CCSDS protocols (telemetry, 
>>telecommand, AOS) that LTP is designed to run over; Ethernet frames carry 
>>data length.  What is the issue here?
>
>The issue is that "having the link layer delver the complete payload"
>is not in general going to work. I believe IP/ATM has, and remember
>IP/X.25 having, exactly this issue where fragmentation does occur
>"lower" down and the path MTU is very hard to get right. I have
>seen this happen with Kerberos/UDP/X.25, where the Kerberos codec
>caught the fragmentation after the Kerberos comms layer missed
>it - early krbv5 code assumed that all Kerberos AS_REQ messages
>would fit in a single UDP packet and that there would be no lower
>layer fragmentation, and hence that a single recvfrom() would be
>enough for an entire AS_REQ. It wasn't.
>
>It may not be common, but it does exist as a corner case, so
>not including the number of offset/length pairs in an RS (or
>equivalent) seems to me very shortsighted.
>
>Also, in a deep-space context, if the comms go down s.t. an RS is
>truncated in just this way, are you telling me that there's no-one
>who'd want to use the bits that arrived already? (Such a change of
>attitude between link and network layers:-) If they did use those
>bits then they'd not know whether they've a full or truncated RS
>and the protocol state machines of the peers are now out of whack
>in an unexpected manner.
>
>Lastly it seems like quite a bad idea from the p-o-v of analysing
>LTP - presumably a formaly analysis would be simplified if all
>LTP PDUs were actually self-describing in the fairly minimal
>sense of allowing detection of PDU truncation.

Okay, I think there is a general issue here that needs to be resolved.  The 
general issue is what level of service LTP can expect from the underlying 
link layer -- or, put another way, what level of service LTP may require of 
the underlying link layer -- or, put yet another way, which underlying link 
protocols LTP may be operated over.

At one extreme -- which is the position from which the LTP draft is 
currently written -- LTP requires that the link layer protocol deliver the 
complete payload (in this case, a single LTP segment) of a single, integral 
link-layer protocol data unit, in which there are no known bit errors, and 
note the length of that delivered payload.  This has the disadvantage of 
limiting LTP to operation over those link layer protocols that can offer 
this level of service; moreover, any implementation errors in those 
protocols will result in LTP operational errors.  The advantage is that LTP 
itself can be somewhat smaller, simpler, and more laconic: there is no need 
to carry in the segment header a segment content length or a CRC, for example.

Alternatively, LTP could require far less of the link layer protocol (that 
is, trust it far less).  This would have the advantage of enabling LTP to 
operate over a wider array of link layer protocols and would reduce its 
vulnerability to implementation errors in those protocols.  The 
disadvantage is that LTP would need to be somewhat more complex and 
inevitably somewhat larger, and more information would need to be carried 
in the segment header.

I'm sure it's clear which side of this question I come down on :-), and I 
think that position is justified by the quality and capability of the 
space-qualified link layer protocols LTP is designed to run over in the 
Interplanetary Internet.  But I certainly agree that this design choice 
might limit the usability of LTP in some terrestrial environments.  Anybody 
out there have any thoughts on this?

Scott

Date: Tue, 06 Apr 2004 12:17:56 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

> Are you sure this is what you want to say?  It sounds a bit like 
> catechism rather than argument.  We're not talking about "handling 
> higher layer data structures", 

Yes, we are. If Block ID is anything other than an indicator
of higher layer PDU structure, then its not what you and the
spec said it was. This really is sending the the angle-brackets
in LTP when the higher layer is using XML!

>> Also, the LTP implementation can't know when to include/omit
>> the block ID without higher layer prompting, so there has
>> to be higher layer code which knows this LTP "feature" so why
>> not have different higher layer code that achieves the effect
>> without requiring the lower layer's co-operation. (E.g. repeating
>> some context information occasionally within the data.)
> 
> The spec says "The mechanism by which the data segments that will carry 
> block ID are selected is a local implementation matter."  If you want 
> the upper-layer protocol to participate in these kinds of decisions, you 
> can provide an implementation-specific mechanism to enable that behavior 
> -- or you can do it another way.

That's not the point. Having the upper layer involved means that
you probably have a better solution - letting the upper layer
handle the repitition of data/structure-indicators itself.

>> The current scheme also requires the higher layer to know how
>> higher layer PDUs are fragmented into LTP segments, which is,
>> again, a bad thing.
> 
> 
> Not at all.  This is precisely what I was explaining it does NOT do.  
> Only the implementation of LTP needs to know how client service data is 
> chopped up into LTP segments, and so that is where the decisions on 
> inserting block ID have to be made.

Then I don't understand how the LTP implementation can ever know
when to include and when not to include the Block ID in a segment.
I really don't.

>> BUT, do you have a concrete example of where this saves the day? If
>> so, then you've a winning argument. But, if not, then I think this
>> feature is just a layering violation pure and simple and shouldn't
>> be kept.
> 
> I don't understand what you mean by "saves the day".  It's a means of 
> conveying information that the client service requires, in a way that is 
> as efficient as the implementation chooses to make it.

What I meant was that I'll shut up if there's an application context
where this mechanism is convincing. For all the applications I can
imagine the higher-layer approach seems better, but then you guys
know more about deep space apps than I do, so I'm asking to be
convinced. Basically, even though its a layering violation, I could
live with that if its a useful enough layering violation:-)

Stephen.

Date: Tue, 06 Apr 2004 12:07:00 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] more ltp comments
Sender: [email-masked]

Scott Burleigh wrote:
> At 02:28 PM 4/5/2004 +0100, Stephen Farrell wrote:
> 
>>>>         - checkpoint serial number (csn) is therefore a counter

I'll come back to this if I still think the same when I've
written code, but I should admit that you've made a reasonable
case that csn's may well be worthwhile. (Not too grudging an
admission I hope:-)

>>>> 6. How do I spot the end of a report segment? I think there's a missing
>>>> counter or overall length somewhere since a report segment can have
>>>> any number of offset/length pairs. Maybe I'm just missing something?
>>>> (My choice would be to change so that the header contains an overall
>>>> length field, but a "number of offset/length pairs" field in the
>>>> report segment would also do.)
>>>
>>> The underlying link layer should give you the length of each segment 
>>> it delivers to LTP.  (I suspect this requirement imposed on the 
>>> underlying link protocol isn't stated explicitly anywhere, and it 
>>> should be.)
>>
>>
>> I think that's a bad assumption/requirement. Even if a lower layer
>> does only present the LTP implementation with what it thinks are
>> "full" blocks, there are still potential cases of lower layer
>> fragmentation where the "full" lower layer block that goes missing
>> is exactly an offset/length pair from an RS. Building Murphy's
>> law into a spec in this way seems like a bad idea.
>>
>> I'm sure there's some networking wisdom somewhere that says that you
>> shouldn't define PDUs at level N, s.t. you can't tell at level N
>> whether you've got a complete PDU or not. Even if there weren't
>> I'd guess that such a "non-determinstic" PDU would be the last thing
>> to use when you're handling/reporting errors.
> 
> 
> All we're talking about is having the link layer protocol deliver the 
> complete payload (in this case, a single LTP segment) of a single, 
> integral link-layer protocol data unit, in which there are no known bit 
> errors, and noting the length of that delivered payload.  I think this 
> is just standard service definition.  I don't know of any link-layer 
> frame definition that can't tell you the length of the upper-layer 
> protocol data payload contained in each frame: either that length is 
> carried explicitly in the frame or else the data length can be easily 
> inferred because the frame length and frame header size are both fixed.  
> Certainly this is no problem for the CCSDS protocols (telemetry, 
> telecommand, AOS) that LTP is designed to run over; Ethernet frames 
> carry data length.  What is the issue here?

The issue is that "having the link layer delver the complete payload"
is not in general going to work. I believe IP/ATM has, and remember
IP/X.25 having, exactly this issue where fragmentation does occur
"lower" down and the path MTU is very hard to get right. I have
seen this happen with Kerberos/UDP/X.25, where the Kerberos codec
caught the fragmentation after the Kerberos comms layer missed
it - early krbv5 code assumed that all Kerberos AS_REQ messages
would fit in a single UDP packet and that there would be no lower
layer fragmentation, and hence that a single recvfrom() would be
enough for an entire AS_REQ. It wasn't.

It may not be common, but it does exist as a corner case, so
not including the number of offset/length pairs in an RS (or
equivalent) seems to me very shortsighted.

Also, in a deep-space context, if the comms go down s.t. an RS is
truncated in just this way, are you telling me that there's no-one
who'd want to use the bits that arrived already? (Such a change of
attitude between link and network layers:-) If they did use those
bits then they'd not know whether they've a full or truncated RS
and the protocol state machines of the peers are now out of whack
in an unexpected manner.

Lastly it seems like quite a bad idea from the p-o-v of analysing
LTP - presumably a formaly analysis would be simplified if all
LTP PDUs were actually self-describing in the fairly minimal
sense of allowing detection of PDU truncation.

[nits deleted]

Stephen.

Date: Tue, 06 Apr 2004 11:45:03 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

Ok. Asbent input from others I guess I'm done on this one
since its largely a matter of "style". (I do still maintain
that my set of flags is better of course:-)

S.

Scott Burleigh wrote:
> At 02:06 PM 4/5/2004 +0100, Stephen Farrell wrote:
> 
>> Scott, Mani,
>>
>>>> > So instead of: Ctrl, E,R,C how about:
>>>> >
>>>> > D: Data: set means data, clear means one of RS/RSA/C/CA
>>>> > U: Unreliable: set means unreliable, clear means reliable (and
>>>> >       SHOULD be the same for the entire session)
>>>> > C: Checkpoint: set means "I want a report, NOW", clear means "no need
>>>> >       to report yet"
>>>> > A: Accelerated delivery: set means "please send up to client as you
>>>> >       get bytes in", clear means "do what you want"
>>>> > E: EOB: as is
>>>> >
>>
>> [...]
>>
>>>
>>> We can still talk about this, but I really think it is a non-issue.  
>>> The bits are labeled for convenience in writing the specification, 
>>> and I think the current labels serve that purpose well enough.
>>
>>
>> I have to say that as a reader of the spec, I found it confusing.
>> So, I'd argue for rejigging them to make it clearer. And IMO a good
>> way to do that is for each bit to have an independent meaning.
> 
> 
> Hmmm.  There are only four bits, which suggests to me that there can be 
> only four labels and four meanings.  The meanings could be independent 
> if the bits were independent flags that would retain the same meaning 
> regardless of the values of the other bits, but that's not what they 
> are; the significance of each value of each bit depends on the context 
> (the values of the other bits).  The best we can do with the labels on 
> those bits is make them somewhat connotative of the bits' functions in 
> the segment type codes.
> 
> If that is too confusing for the reader then we should probably ditch 
> the bit labels altogether and just enumerate the type codes without 
> offering any analysis.  This may be different for different readers, 
> though; I find them helpful, myself.
> 
>> [...]
>>
>>> Actually the spec already does enable accelerated delivery for blocks 
>>> that are transmitted reliably (see the (b) clause in the first 
>>> paragraph of 9.9), and the reason for this is that -- just as you say 
>>> -- some client services might want immediate delivery of data 
>>> segments even out of transmission order.  This is a notion that is 
>>> inherited directly from CFDP.
>>
>>
>> I like this feature, but don't like having it defined waaaay down there
>> in section 9.9:-)
> 
> 
> There is a forward reference to it in 5.3, but we could certainly make 
> that more explicit.
> 
>> That section also references the "service quality
>> indicator" field, which I thought we'd (at least tentatively) agreed
>> would be better handled using these header bits. So isn't some
>> change going to be made in any case?
> 
> 
> Yes, the reference to the service quality indicator will have to come out.
> 
> Scott
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Mon, 05 Apr 2004 09:39:50 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

At 02:44 PM 4/5/2004 +0100, Stephen Farrell wrote:
>>>>>>>19. Block ID (7.2.1) If block ID is basically an
>>
>>>Ok. But what processing is simplified? That's what I don't get.
>>Struggling a bit, myself, to articulate something that has been intuitive 
>>for me, here's what I come up with:
>>Block ID has to be conveyed at least once per block of client service 
>>data, so that the application can know what to do with the block.
>>A given block might be transmitted in N data segments, but we don't need 
>>to send block ID N times -- and in fact might prefer not to, which would 
>>save us some bandwidth.
>>We don't expose block segmentation to the sending client service.  At the 
>>same time, we want to give the receiving client service the option to 
>>receive each data segment's increment of client data as it arrives, 
>>rather than waiting for delivery of the whole block when it has all been 
>>received.
>>If Block ID were simply (and invisibly, to LTP) provided at the front of 
>>the client data by the client service, failure to receive the first data 
>>segment would mean that any incremental client data delivery to the 
>>receiving client service might be useless.  We need the ability to 
>>provide Block ID multiple times per block, i.e., in multiple segments.
>>But depending on how clean the link is (how likely we are to lose any 
>>single segment) we may not want it in every segment; we want to be able 
>>to insert block ID selectively into some deployment-specific subset of 
>>the segments generated for any block.  Since segmentation is not exposed 
>>to the sending client service, the client service can't do this; so LTP 
>>has to.  So LTP needs to have some place to put Block ID in every data 
>>segment, omitting it where necessary.
>
>I have to say I'm not convinced. The higher layer should handle
>higher layer data structures.

Are you sure this is what you want to say?  It sounds a bit like catechism 
rather than argument.  We're not talking about "handling higher layer data 
structures", we're talking about encapsulating two hunks of payload data 
rather than one and encapsulating them in different ways to improve 
performance.

>Also, the LTP implementation can't know when to include/omit
>the block ID without higher layer prompting, so there has
>to be higher layer code which knows this LTP "feature" so why
>not have different higher layer code that achieves the effect
>without requiring the lower layer's co-operation. (E.g. repeating
>some context information occasionally within the data.)

The spec says "The mechanism by which the data segments that will carry 
block ID are selected is a local implementation matter."  If you want the 
upper-layer protocol to participate in these kinds of decisions, you can 
provide an implementation-specific mechanism to enable that behavior -- or 
you can do it another way.

>The current scheme also requires the higher layer to know how
>higher layer PDUs are fragmented into LTP segments, which is,
>again, a bad thing.

Not at all.  This is precisely what I was explaining it does NOT do.  Only 
the implementation of LTP needs to know how client service data is chopped 
up into LTP segments, and so that is where the decisions on inserting block 
ID have to be made.

>BUT, do you have a concrete example of where this saves the day? If
>so, then you've a winning argument. But, if not, then I think this
>feature is just a layering violation pure and simple and shouldn't
>be kept.

I don't understand what you mean by "saves the day".  It's a means of 
conveying information that the client service requires, in a way that is as 
efficient as the implementation chooses to make it.

>(Next thing you'll be wanting to put "<foo" at the front of a set
>of segments and "/>" at the end, and reinventing XML:-)

No, I don't think that's a very good idea.

Scott 

Date: Mon, 05 Apr 2004 09:27:54 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] more ltp comments
Sender: [email-masked]

At 02:28 PM 4/5/2004 +0100, Stephen Farrell wrote:
>>>         - checkpoint serial number (csn) is therefore a counter
>>>         and "not equal..." etc. just means "greater than last csn" or am I
>>>         expected to store all csn's I've seen in a session?
>>The latter.
>
>Big YUK. What's the worst case here in terms of storage? Seems
>unnecessarily bad or am I as usual missing something?

Worst case will depend on the implementation of the sender.  A sane 
implementation will normally have only one checkpoint per session (the last 
data segment in the original transmission); the response will normally be a 
single RS; if retransmission is required then the terminus of the 
retransmission will be another single checkpoint; etc.

But if the sender for some reason wanted highly accelerated retransmission 
and turned on the checkpoint bit for lots of data segments, you would have 
a lot of checkpoints to track.  This might conceivably be advantageous in 
some deep space deployments, which is why it's in the spec; CFDP offers 
this feature.  If you're going to implement both ends of an LTP link for 
your own application, though, then you've got control of this stuff 
yourself.  Don't let it happen.

Even if you're implementing only the receiving end of an LTP link you can 
defend yourself against excessive checkpointing without violating the spec: 
9.11 says you can simply cancel the session if reception of a given 
checkpoint would push you over the management-configured reception 
reporting limit.

>>>       Not sure I
>>>         like it very much either way mind you:-() Do we think 
>>> retransmission
>>>         will be so common that this helps?
>>
>>Not necessarily, we just want to be sure we handle it without any fuss 
>>when it does happen.
>>
>>>       Presumably, if retransmission were
>>>         very uncommon I could drop the csn idea entirely and just handle
>>>         all report during a session independnently (I think I'd prefer 
>>> that.)
>
>You didn't asnwer that.

Sorry, I didn't notice that it was a question.

>Could the whole csn stuff be dropped given
>that I have the RS/RSA mechanism?

Reports need to reference checkpoints, to enable the sender to know which 
timers can be turned off (to prevent unnecessary retransmission of the 
checkpoints).  There can be multiple checkpoints with the same or 
overlapping scope, because checkpoints are delivered both on original 
transmission and on retransmission (which can occur several times), so the 
only way to reference a specific checkpoint is by csn.  So no, I don't 
think the csn mechanism can be dropped.

>>>5. Section 9.11 again. Why can't I handle all reports in the same way as
>>>I handle asychronous ones? The rule about "primary" and "seconday"
>>>report bounds seems very opaque to me (maybe it'll get clear as I
>>>write code), so I'd expect lots of bugs there implementations. Could
>>>we try to go for the simpler approach? (And even in the "simpler" case,
>>>why do I need to tie the lower bound with the previous "primary" upper
>>>bound? Wouldn't it be enough just to say that you shouldn't leave any
>>>"gaps" in reports?)
>>This part of the spec admittedly sacrifices simplicity for performance in 
>>the event that retransmission is necessary.  It has gotten a lot of 
>>thought, and I'm pretty sure it is right, but please speak up if you see 
>>cases in which it does not work.
>
>Sure. It doesn't work when I write the wrong code for it:-)
>
>Can you elaborate on the performance improvement? I don't get that.
>Surely if you want to be clever you can include that cleverness in how
>often and which RS segments you send and get the same performance?
>I'd be interested in a case where that doesn't work.

The point here is to make all of the reporting and all data retransmission 
happen upon arrival of segments that request it, rather than upon 
expiration of arbitrary periodic timers (as in the CFDP design).  The 
reason to do this is that those timers can be hard to get right, due to 
timing variability that depends on queuing delay and radiation data rate -- 
which we emphatically do not want to expose to peer LTP engines.  If 
retransmission timers expire later than they should, data delivery latency 
is increased and storage utilization is degraded; if they go off earlier 
than they should, unnecessary retransmission degrades link 
utilization.  Relying on timers for this purpose is simple but not optimal.

There's no claim that getting this code right will be effortless.  I think, 
though, that it is the most efficient way to accomplish this sort of ARQ, 
given that accelerated retransmission is possible.

Now, if we're really going for simplicity, all kinds of simplifications can 
be made if we ditch accelerated retransmission.  Maybe that makes sense, 
maybe this is a feature that users really will never need; I dunno.  But 
abandoning a feature merely because we're worried that we'll have a hard 
time getting the code to work doesn't seem right to me.

>>>6. How do I spot the end of a report segment? I think there's a missing
>>>counter or overall length somewhere since a report segment can have
>>>any number of offset/length pairs. Maybe I'm just missing something?
>>>(My choice would be to change so that the header contains an overall
>>>length field, but a "number of offset/length pairs" field in the
>>>report segment would also do.)
>>The underlying link layer should give you the length of each segment it 
>>delivers to LTP.  (I suspect this requirement imposed on the underlying 
>>link protocol isn't stated explicitly anywhere, and it should be.)
>
>I think that's a bad assumption/requirement. Even if a lower layer
>does only present the LTP implementation with what it thinks are
>"full" blocks, there are still potential cases of lower layer
>fragmentation where the "full" lower layer block that goes missing
>is exactly an offset/length pair from an RS. Building Murphy's
>law into a spec in this way seems like a bad idea.
>
>I'm sure there's some networking wisdom somewhere that says that you
>shouldn't define PDUs at level N, s.t. you can't tell at level N
>whether you've got a complete PDU or not. Even if there weren't
>I'd guess that such a "non-determinstic" PDU would be the last thing
>to use when you're handling/reporting errors.

All we're talking about is having the link layer protocol deliver the 
complete payload (in this case, a single LTP segment) of a single, integral 
link-layer protocol data unit, in which there are no known bit errors, and 
noting the length of that delivered payload.  I think this is just standard 
service definition.  I don't know of any link-layer frame definition that 
can't tell you the length of the upper-layer protocol data payload 
contained in each frame: either that length is carried explicitly in the 
frame or else the data length can be easily inferred because the frame 
length and frame header size are both fixed.  Certainly this is no problem 
for the CCSDS protocols (telemetry, telecommand, AOS) that LTP is designed 
to run over; Ethernet frames carry data length.  What is the issue here?

>>>7. Here's a scenario. Alice sends 3 DS's containing respectively
>>>bytes 0:999, 1000:1999 and 2000:2999 of a 3000 byte long message.
>>>Now say Bob gets the all these, but somehow detects that there
>>>were errors near bytes 1900 and 2100 (just bear with me, don't
>>>say that can't happen for now:-). Can Bob send back a report
>>>to Alice with UB=2999;LB=0;{Off=0;Len=1800};{Off=2200;Len=799}?
>>>And if he does do that, then what should Alice do?
>>>         - Re-Tx DS's 2 & 3 ?
>>>         - Create a new DS containing bytes 1800 to 2199 inclusive?
>>>         - Whichever of those she wants?
>>>[I'd be very much in favor of the last answer there.]
>>
>>If Alice receives an RS stating that bytes 1800-2199 inclusive were not 
>>received, then she should retransmit those bytes in one or more data 
>>segments.  She is also free to retransmit bytes that have already been 
>>reported as successfully received, although she might not be a 
>>particularly popular implementation of LTP if she did.  So I think the 
>>answer is the one you favor.
>
>Great. Be good if the spec were explicit that this is allowed, since
>I got the opposite impression at first reading.

Can you say which words in which section gave you this impression?  We 
should fix that.

>>>2. 9.13, 3rd para calling this a "countdown timer" is a bit wrong,
>>>isn't this just a re-transmit counter and not really a timer at
>>>all?
>>Well, it's a "timer" inasmuch as it is a device that causes some action 
>>to occur after some specified period of time has passed.
>
>Weak. Its a counter. Timers go along with clocks and measure time.
>Counters involve increments/decrements and a just integers. But,
>this is not in the "nit" section for nothing:-)

The thing that UNIX calls a "timer" (more specifically, an "interval 
timer"), which you configure by calling setitimer(), is the sort of thing 
we're calling a "timer" here.  I don't think most readers will be confused.

>>>4. Section 11 implies that a MIB will contain the LTT between
>>>peers. That wouldn't be in a MIB (too much information for SNMP
>>>I'd reckon). Better to just say that relevant, and sufficiently
>>>accurate, ephemeris information needs to be available to the
>>>nodes.
>>We need to do more work on this section anyway, but MIB here is used in 
>>an abstract sense as the source of all information needed to operate the 
>>protocol that must be supplied by network management -- nothing to do 
>>with SNMP specifically.
>
>Even in the abtract, I'd think of a MIB as a not-too-complicated
>database. Ephemeris handling is too complicated to fit that IMO,
>especially since there'll be some sort of interpolation function
>needed as well as the massive amounts of data.

Because it's an abstract source of information, it can be arbitrarily 
complicated; we don't design it here.  This information needs to come from 
somewhere; we could have different names for different abstract sources of 
information, but I don't see how that would be advantageous.

Scott 

Date: Mon, 05 Apr 2004 08:10:06 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

At 02:06 PM 4/5/2004 +0100, Stephen Farrell wrote:

>Scott, Mani,
>
>>> > So instead of: Ctrl, E,R,C how about:
>>> >
>>> > D: Data: set means data, clear means one of RS/RSA/C/CA
>>> > U: Unreliable: set means unreliable, clear means reliable (and
>>> >       SHOULD be the same for the entire session)
>>> > C: Checkpoint: set means "I want a report, NOW", clear means "no need
>>> >       to report yet"
>>> > A: Accelerated delivery: set means "please send up to client as you
>>> >       get bytes in", clear means "do what you want"
>>> > E: EOB: as is
>>> >
>[...]
>>
>>We can still talk about this, but I really think it is a non-issue.  The 
>>bits are labeled for convenience in writing the specification, and I 
>>think the current labels serve that purpose well enough.
>
>I have to say that as a reader of the spec, I found it confusing.
>So, I'd argue for rejigging them to make it clearer. And IMO a good
>way to do that is for each bit to have an independent meaning.

Hmmm.  There are only four bits, which suggests to me that there can be 
only four labels and four meanings.  The meanings could be independent if 
the bits were independent flags that would retain the same meaning 
regardless of the values of the other bits, but that's not what they are; 
the significance of each value of each bit depends on the context (the 
values of the other bits).  The best we can do with the labels on those 
bits is make them somewhat connotative of the bits' functions in the 
segment type codes.

If that is too confusing for the reader then we should probably ditch the 
bit labels altogether and just enumerate the type codes without offering 
any analysis.  This may be different for different readers, though; I find 
them helpful, myself.

>[...]
>>Actually the spec already does enable accelerated delivery for blocks 
>>that are transmitted reliably (see the (b) clause in the first paragraph 
>>of 9.9), and the reason for this is that -- just as you say -- some 
>>client services might want immediate delivery of data segments even out 
>>of transmission order.  This is a notion that is inherited directly from CFDP.
>
>I like this feature, but don't like having it defined waaaay down there
>in section 9.9:-)

There is a forward reference to it in 5.3, but we could certainly make that 
more explicit.

>That section also references the "service quality
>indicator" field, which I thought we'd (at least tentatively) agreed
>would be better handled using these header bits. So isn't some
>change going to be made in any case?

Yes, the reference to the service quality indicator will have to come out.

Scott 

Date: Mon, 05 Apr 2004 14:44:13 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

>>>>>> 19. Block ID (7.2.1) If block ID is basically an
>>
>
>> Ok. But what processing is simplified? That's what I don't get.
> 
> Struggling a bit, myself, to articulate something that has been 
> intuitive for me, here's what I come up with:
> 
> Block ID has to be conveyed at least once per block of client service 
> data, so that the application can know what to do with the block.
> 
> A given block might be transmitted in N data segments, but we don't need 
> to send block ID N times -- and in fact might prefer not to, which would 
> save us some bandwidth.
> 
> We don't expose block segmentation to the sending client service.  At 
> the same time, we want to give the receiving client service the option 
> to receive each data segment's increment of client data as it arrives, 
> rather than waiting for delivery of the whole block when it has all been 
> received.
> 
> If Block ID were simply (and invisibly, to LTP) provided at the front of 
> the client data by the client service, failure to receive the first data 
> segment would mean that any incremental client data delivery to the 
> receiving client service might be useless.  We need the ability to 
> provide Block ID multiple times per block, i.e., in multiple segments.  
> But depending on how clean the link is (how likely we are to lose any 
> single segment) we may not want it in every segment; we want to be able 
> to insert block ID selectively into some deployment-specific subset of 
> the segments generated for any block.  Since segmentation is not exposed 
> to the sending client service, the client service can't do this; so LTP 
> has to.  So LTP needs to have some place to put Block ID in every data 
> segment, omitting it where necessary.

I have to say I'm not convinced. The higher layer should handle
higher layer data structures.

Also, the LTP implementation can't know when to include/omit
the block ID without higher layer prompting, so there has
to be higher layer code which knows this LTP "feature" so why
not have different higher layer code that achieves the effect
without requiring the lower layer's co-operation. (E.g. repeating
some context information occasionally within the data.)

The current scheme also requires the higher layer to know how
higher layer PDUs are fragmented into LTP segments, which is,
again, a bad thing.

BUT, do you have a concrete example of where this saves the day? If
so, then you've a winning argument. But, if not, then I think this
feature is just a layering violation pure and simple and shouldn't
be kept.

(Next thing you'll be wanting to put "<foo" at the front of a set
of segments and "/>" at the end, and reinventing XML:-)

>> Agreed. First thing I'd do would be to construct a threat model,
>> desribing some use cases and listing potential threats for each.
>> Maybe you've got something like that lying around? (The use-cases
>> part anyway.)
> 
> Not a chance.  If you have something at hand, please pass it on.

'Fraid not. I might have a chance to do something on this as I
implement LTP for my own application though, but it won't be
directly on an IPN use case since that's not what my funding's
for;-)

Stephen.

Date: Mon, 05 Apr 2004 14:28:34 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] more ltp comments
Sender: [email-masked]

Scott,

As usual, "Ok, then" stuff deleted.

>>         - checkpoint serial number (csn) is therefore a counter
>>         and "not equal..." etc. just means "greater than last csn" or 
>> am I
>>         expected to store all csn's I've seen in a session?
> 
> The latter.

Big YUK. What's the worst case here in terms of storage? Seems
unnecessarily bad or am I as usual missing something?

> 
>>       Not sure I
>>         like it very much either way mind you:-() Do we think 
>> retransmission
>>         will be so common that this helps?
> 
> 
> Not necessarily, we just want to be sure we handle it without any fuss 
> when it does happen.
> 
>>       Presumably, if retransmission were
>>         very uncommon I could drop the csn idea entirely and just handle
>>         all report during a session independnently (I think I'd prefer 
>> that.)

You didn't asnwer that.  Could the whole csn stuff be dropped given
that I have the RS/RSA mechanism?

>>
>> 5. Section 9.11 again. Why can't I handle all reports in the same way as
>> I handle asychronous ones? The rule about "primary" and "seconday"
>> report bounds seems very opaque to me (maybe it'll get clear as I
>> write code), so I'd expect lots of bugs there implementations. Could
>> we try to go for the simpler approach? (And even in the "simpler" case,
>> why do I need to tie the lower bound with the previous "primary" upper
>> bound? Wouldn't it be enough just to say that you shouldn't leave any
>> "gaps" in reports?)
> 
> This part of the spec admittedly sacrifices simplicity for performance 
> in the event that retransmission is necessary.  It has gotten a lot of 
> thought, and I'm pretty sure it is right, but please speak up if you see 
> cases in which it does not work.

Sure. It doesn't work when I write the wrong code for it:-)

Can you elaborate on the performance improvement? I don't get that.
Surely if you want to be clever you can include that cleverness in how
often and which RS segments you send and get the same performance?
I'd be interested in a case where that doesn't work.

>> 6. How do I spot the end of a report segment? I think there's a missing
>> counter or overall length somewhere since a report segment can have
>> any number of offset/length pairs. Maybe I'm just missing something?
>> (My choice would be to change so that the header contains an overall
>> length field, but a "number of offset/length pairs" field in the
>> report segment would also do.)
> 
> The underlying link layer should give you the length of each segment it 
> delivers to LTP.  (I suspect this requirement imposed on the underlying 
> link protocol isn't stated explicitly anywhere, and it should be.)

I think that's a bad assumption/requirement. Even if a lower layer
does only present the LTP implementation with what it thinks are
"full" blocks, there are still potential cases of lower layer
fragmentation where the "full" lower layer block that goes missing
is exactly an offset/length pair from an RS. Building Murphy's
law into a spec in this way seems like a bad idea.

I'm sure there's some networking wisdom somewhere that says that you
shouldn't define PDUs at level N, s.t. you can't tell at level N
whether you've got a complete PDU or not. Even if there weren't
I'd guess that such a "non-determinstic" PDU would be the last thing
to use when you're handling/reporting errors.

> 
>> 7. Here's a scenario. Alice sends 3 DS's containing respectively
>> bytes 0:999, 1000:1999 and 2000:2999 of a 3000 byte long message.
>> Now say Bob gets the all these, but somehow detects that there
>> were errors near bytes 1900 and 2100 (just bear with me, don't
>> say that can't happen for now:-). Can Bob send back a report
>> to Alice with UB=2999;LB=0;{Off=0;Len=1800};{Off=2200;Len=799}?
>> And if he does do that, then what should Alice do?
>>         - Re-Tx DS's 2 & 3 ?
>>         - Create a new DS containing bytes 1800 to 2199 inclusive?
>>         - Whichever of those she wants?
>> [I'd be very much in favor of the last answer there.]
> 
> 
> If Alice receives an RS stating that bytes 1800-2199 inclusive were not 
> received, then she should retransmit those bytes in one or more data 
> segments.  She is also free to retransmit bytes that have already been 
> reported as successfully received, although she might not be a 
> particularly popular implementation of LTP if she did.  So I think the 
> answer is the one you favor.

Great. Be good if the spec were explicit that this is allowed, since
I got the opposite impression at first reading.

>> 2. 9.13, 3rd para calling this a "countdown timer" is a bit wrong,
>> isn't this just a re-transmit counter and not really a timer at
>> all?
> 
> Well, it's a "timer" inasmuch as it is a device that causes some action 
> to occur after some specified period of time has passed.

Weak. Its a counter. Timers go along with clocks and measure time.
Counters involve increments/decrements and a just integers. But,
this is not in the "nit" section for nothing:-)

>> 4. Section 11 implies that a MIB will contain the LTT between
>> peers. That wouldn't be in a MIB (too much information for SNMP
>> I'd reckon). Better to just say that relevant, and sufficiently
>> accurate, ephemeris information needs to be available to the
>> nodes.
> 
> We need to do more work on this section anyway, but MIB here is used in 
> an abstract sense as the source of all information needed to operate the 
> protocol that must be supplied by network management -- nothing to do 
> with SNMP specifically.

Even in the abtract, I'd think of a MIB as a not-too-complicated
database. Ephemeris handling is too complicated to fit that IMO,
especially since there'll be some sort of interpolation function
needed as well as the massive amounts of data.

Stephen.

Date: Mon, 05 Apr 2004 14:06:35 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

Scott, Mani,

>> > So instead of: Ctrl, E,R,C how about:
>> >
>> > D: Data: set means data, clear means one of RS/RSA/C/CA
>> > U: Unreliable: set means unreliable, clear means reliable (and
>> >       SHOULD be the same for the entire session)
>> > C: Checkpoint: set means "I want a report, NOW", clear means "no need
>> >       to report yet"
>> > A: Accelerated delivery: set means "please send up to client as you
>> >       get bytes in", clear means "do what you want"
>> > E: EOB: as is
>> >
[...]
> 
> 
> We can still talk about this, but I really think it is a non-issue.  The 
> bits are labeled for convenience in writing the specification, and I 
> think the current labels serve that purpose well enough.

I have to say that as a reader of the spec, I found it confusing.
So, I'd argue for rejigging them to make it clearer. And IMO a good
way to do that is for each bit to have an independent meaning.

[...]
> Actually the spec already does enable accelerated delivery for blocks 
> that are transmitted reliably (see the (b) clause in the first paragraph 
> of 9.9), and the reason for this is that -- just as you say -- some 
> client services might want immediate delivery of data segments even out 
> of transmission order.  This is a notion that is inherited directly from 
> CFDP.

I like this feature, but don't like having it defined waaaay down there
in section 9.9:-) That section also references the "service quality
indicator" field, which I thought we'd (at least tentatively) agreed
would be better handled using these header bits. So isn't some
change going to be made in any case?

All in all, I'd find the bit definitions above or similar easier
to read and write code for.

Stephen.

PS: the reason I changed from "Control" to "Data" as a bit name
was so they'd all have different initials, hence referring
to "C" would then mean "Checkpoint".

Date: Mon, 05 Apr 2004 13:55:47 +0100
From: Stephen Farrell <[email-masked]>
To: Leigh Torgerson <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

Leigh,

> if the receiver doesn't already know how to synch up on the symbol 
> stream and decode/unrandomize the data, then any header info in the 
> [happy clump of data] is moot.

Yep.

> If there was a "switch" sublayer that could use the codec header to 
> decide between multiple transmission paths with different codes (maybe 
> RS on a long-haul link and convolutional coding on a shorter link?), or 
> something like that, maybe a codec header would make sense.

Yes, that's what I was thinking (though it'd also be of some use
perhaps when/if we think about data integrity for LTP).

This might also answer the other queries about what I meant by
a "codec" field - basically, it tells the LTP implementation about
what en/decoding schemes are used below.

But, I can also live without it, which might be an even quicker
way to answer those queries:-)

Stephen.

Date: Sat, 03 Apr 2004 13:18:20 -0800
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] more ltp comments
Sender: [email-masked]

At 04:36 PM 4/2/2004 +0100, Stephen Farrell wrote:
>1. What happens if an LTP engine's queue is full? Say if I normally
>queue packets in CF and some inbound packet (part of a reliable delivery)
>causes the CF to become full - do I drop the packet and forget I've seen
>it? (And so possibly recover if CF space frees up while I'm playing the
>RS/RSA game with the peer.) Or do I send an immediate "C", or a "C"
>depending on some configuration?

I'm inclined to leave that as an implementation decision.  The protocol 
works either way, and the right decision might very well be different in 
different environments.

>2. I've just noticed that the DS structure means that I only get to
>know the overall length of a block when I've gotten all the segments.
>Would be not be nice to be able to indicate the overall length earlier
>so that the recipient can allocate/reserve resources? If so, then maybe
>define a new optional header for this purpose.

Maybe; CFDP's "metadata PDU" does this, but I haven't seen much evidence of 
its usefulness so far.  Anybody else have any thoughts on this?

>3. Asychronous report requesting. I don't think I want to implement this
>for my application.

No problem, it is explicitly an implementation matter (9.11(b)).

>Can you (further) explain to me why I'd want it and
>in particular, how some code would decide when to exercise it? I could
>imagine turning it on/off by configuration, but other that anti-DoS
>(which is still open) can't see what algorithm (that I care about)
>would decide to suddenly turn on such requests.

I'm not at all sure I can make a case for it, but it's a feature that 
seemed desirable enough to include in CFDP.  Since it doesn't seem to cost 
anything (you have to handle multiple concurrent RS's anyway due to the 
possibility of multiple checkpoints), I'm inclined to leave it in the spec.

>4. Checkpoint handling. Taking an example from 9.11, it says, in part:
>"This procedure is triggered by either (a) reception of a checkpoint (a
>data segment with Request bit set to 1) whose checkpoint serial number
>is not equal to that of any previously issued RS segment and whose
>service quality indicator is set to 1 (reliable transmission) or (b) an
>implementation-specific circumstance pertaining to a particular block
>reception session for which no EOB has yet been received ("asynchronous"
>reception reporting)."
>
>         Two questions:
>         - can you tell me some "implementation specific circumstance"
>         that'd trigger this? (Maybe this is the same as my previous question
>         above?) [I found one in section 12 - see below]

Right, same answer as above.

>         - checkpoint serial number (csn) is therefore a counter
>         and "not equal..." etc. just means "greater than last csn" or am I
>         expected to store all csn's I've seen in a session?

The latter.

>       Not sure I
>         like it very much either way mind you:-() Do we think retransmission
>         will be so common that this helps?

Not necessarily, we just want to be sure we handle it without any fuss when 
it does happen.

>       Presumably, if retransmission were
>         very uncommon I could drop the csn idea entirely and just handle
>         all report during a session independnently (I think I'd prefer that.)
>
>5. Section 9.11 again. Why can't I handle all reports in the same way as
>I handle asychronous ones? The rule about "primary" and "seconday"
>report bounds seems very opaque to me (maybe it'll get clear as I
>write code), so I'd expect lots of bugs there implementations. Could
>we try to go for the simpler approach? (And even in the "simpler" case,
>why do I need to tie the lower bound with the previous "primary" upper
>bound? Wouldn't it be enough just to say that you shouldn't leave any
>"gaps" in reports?)

This part of the spec admittedly sacrifices simplicity for performance in 
the event that retransmission is necessary.  It has gotten a lot of 
thought, and I'm pretty sure it is right, but please speak up if you see 
cases in which it does not work.

>6. How do I spot the end of a report segment? I think there's a missing
>counter or overall length somewhere since a report segment can have
>any number of offset/length pairs. Maybe I'm just missing something?
>(My choice would be to change so that the header contains an overall
>length field, but a "number of offset/length pairs" field in the
>report segment would also do.)

The underlying link layer should give you the length of each segment it 
delivers to LTP.  (I suspect this requirement imposed on the underlying 
link protocol isn't stated explicitly anywhere, and it should be.)

>7. Here's a scenario. Alice sends 3 DS's containing respectively
>bytes 0:999, 1000:1999 and 2000:2999 of a 3000 byte long message.
>Now say Bob gets the all these, but somehow detects that there
>were errors near bytes 1900 and 2100 (just bear with me, don't
>say that can't happen for now:-). Can Bob send back a report
>to Alice with UB=2999;LB=0;{Off=0;Len=1800};{Off=2200;Len=799}?
>And if he does do that, then what should Alice do?
>         - Re-Tx DS's 2 & 3 ?
>         - Create a new DS containing bytes 1800 to 2199 inclusive?
>         - Whichever of those she wants?
>[I'd be very much in favor of the last answer there.]

If Alice receives an RS stating that bytes 1800-2199 inclusive were not 
received, then she should retransmit those bytes in one or more data 
segments.  She is also free to retransmit bytes that have already been 
reported as successfully received, although she might not be a particularly 
popular implementation of LTP if she did.  So I think the answer is the one 
you favor.

>8. section 9.17, 3rd para says:
>"It is possible that the Cancel segment is being retransmitted because a
>previous Cancel Acknowledgment was lost, in which case there will no
>longer be any record of the session of which the segment is one token.
>If so, no further action is taken."
>How is that (the "no longer ... any record") detected? The sender of
>the CA cannot be assumed to know how many times the peer (who sent
>the C) is willing to retry. Probably I'm confused, but I think I
>always have to send a CA when I get a C for a session I know about.

You actually have to send a CA whenever you get a C, whether it's for a 
session you know about or not.  But you take no *further* action (that is, 
you don't proceed with canceling the session) if the referenced session is 
one you don't know about, possibly because you canceled it upon receipt of 
a prior Cancel segment for that session.

>9. How about adding the following guidance (based on how DHCP works,
>not an original thought:-). Session IDs are used during sessions,
>but sometimes (e.g. the case above) a segment may arrive "just after"
>a session has been forgotten. Given that nodes know the latencies
>involved, how about adding a recommendation that session IDs should
>be maintained for an additional latency+configured period after
>they expire? That'd (probably) allow the right CA to be sent in
>the case above.
>The information to be maintained should minimally be the session ID,
>but could (at the implemters disgression) include other session
>state (though I'm not sure what's useful right now, if CF isn't
>full-ish and no-one's DoS-ing me, I'd probhaby keep it all for a
>while, and just periodically flush old sessions).

Sure, the CFDP "history timer" notion operates along these lines, but I 
don't see what it really buys you.  You're always supposed to acknowledge 
every Cancel, whether you've forgotten about the session or not, and you 
obviously never have to cancel a session that you don't know anything about 
(for whatever reason).  That seems simple and comprehensive.

>Nits/Quibbles
>-------------
>
>1. p42 (9.11, 3rd para) says "As many report segments are produced
>as are required..."
>I think that should be "A report segment is produced containing as
>many offset/length pairs as are required..." (Though maybe that
>depends on some of the above technical comments.)

You might need multiple segments because of the size constraints imposed by 
the underlying communication service (cf. the rest of that sentence).

>2. 9.13, 3rd para calling this a "countdown timer" is a bit wrong,
>isn't this just a re-transmit counter and not really a timer at
>all?

Well, it's a "timer" inasmuch as it is a device that causes some action to 
occur after some specified period of time has passed.

>(Also - the next para talks about releasing buffer space,
>which is not appropriate in a protocol specification, other than
>as advisory text!)

Good point, this should be advisory.

>3. 9.19 says "are" many times, but it could mostly be "can" instead?
>In my implementation I think I'll have a periodic garbage collect
>rather than release buffers at the 1st opportunity. That shouldn't
>be cause for non-conformance.

You're right.  The intent is to prevent link performance degradation due to 
the transmission of stuff that need not be transmitted (because the session 
has been canceled); an implementation that failed to honor that intent 
would be an unsatisfactory implementation but not a non-compliant 
one.  This text should be advisory.

>4. Section 11 implies that a MIB will contain the LTT between
>peers. That wouldn't be in a MIB (too much information for SNMP
>I'd reckon). Better to just say that relevant, and sufficiently
>accurate, ephemeris information needs to be available to the
>nodes.

We need to do more work on this section anyway, but MIB here is used in an 
abstract sense as the source of all information needed to operate the 
protocol that must be supplied by network management -- nothing to do with 
SNMP specifically.

>5. Section 12 mentions CFDP's "immediate" mode and says that's
>a special case of asynchronous mode, well that's true, but I'd
>have liked this example earlier since it answers a question I
>had about whether there were any interesting algorithmic ways
>to trigger an asynch. report.

Sure, that would be easy to add.

Scott

Date: Sat, 03 Apr 2004 12:29:52 -0800
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

At 04:18 PM 4/2/2004 -0500, Manikantan Ramadas wrote:
>Hi Mr.Farrell,
>
>   Please follow my comments inline :
>
> > I like this change, but would like it even more if
> > the bits had better names and were changed about
> > somewhat - their meaning's are a little opaque to me
> > as they stand (probably as a result of how they've
> > evolved I'd guess).
> >
> > So instead of: Ctrl, E,R,C how about:
> >
> > D: Data: set means data, clear means one of RS/RSA/C/CA
> > U: Unreliable: set means unreliable, clear means reliable (and
> >       SHOULD be the same for the entire session)
> > C: Checkpoint: set means "I want a report, NOW", clear means "no need
> >       to report yet"
> > A: Accelerated delivery: set means "please send up to client as you
> >       get bytes in", clear means "do what you want"
> > E: EOB: as is
> >
> > Does that capture all the combinations? If so, it'd certainly
> > be clearer to me (and also de-couples reliability and
> > accelerated/deferred delivery, which makes sense IMO). It
> > does use an extra bit, but then there's one available.
> >
> > What do you think?
>
>   Well the motivation for "Ctrl" bit was exactly the same as what you
>propose as the "Data" bit in the flag, but we are just representing
>the inverse of it. If the Ctrl bit is 1, it is any kind of control
>segment and 0 implies non-control segments which in our case can only
>be Data segments. The two are essentially the same. May be calling it
>the D/C bit (for Data/Control) might be easier?
>
>   That aside, I have to agree that the bits are not independent of
>each other. For example what the E(Exception) bit means depends on
>whether it is a Data/Ctrl segment. Similarly the C(Closure) bit's
>semantics of what it closes depends on the other bits. It indicates
>
>o EOB when set in a Data segment
>o Report ACK if closing a report segment
>o Cancel/ACK if closing a Cancel segment
>
>as you may see from the table in Sec. 7.1.2.
>
>   We argued about this [the fact that the bits are dependent on one
>another] before, and decided to postpone discussion on that for later.
>May be we should just have 4-bit opcodes? We can have some of the
>opcodes undefined in the middle of all 16 possible opcodes,
>if we cared about bit-masking to figure out classes of segments. I
>don't know.

We can still talk about this, but I really think it is a non-issue.  The 
bits are labeled for convenience in writing the specification, and I think 
the current labels serve that purpose well enough.

>But coming to the interesting argument you make for decoupling
>accelerated/deferred delivery from reliable/unreliable delivery.
>Clearly, right now LTP does accelerated delivery only
>when the block is being transmitted unreliably. A typical example is
>when you are transmitting say Telemetry data contiguously and it is
>alright if you missed one record as you can make up from subsequent
>telemetry records. Do you envision quite some applications that could
>use reliable, but out-of-order delivery of segments? May be those
>applications should build reliability on top of their own as we see
>protocols built on top of UDP that do retransmissions and stuff in the
>Internet? What are your thoughts Mr.Burleigh? Others?

Actually the spec already does enable accelerated delivery for blocks that 
are transmitted reliably (see the (b) clause in the first paragraph of 
9.9), and the reason for this is that -- just as you say -- some client 
services might want immediate delivery of data segments even out of 
transmission order.  This is a notion that is inherited directly from CFDP.

> > And since I'm making suggestions, how about adding that
> > "codec" field (hopefully suggested by Leigh) just after
> > the version number in the header? I think that'd justify
> > an entire byte or even an SDNV (I could imagine going
> > over the 255 values, but you'd probably have rev'd the
> > version before that so a byte's enough for now).
>
>   I am not sure what you mean by codecs exactly. Do you envision the
>codec field to identify the link protocol below?

I'm a little confused by this too.  If what's meant is something like a 
sub-version number that indicates how to parse the header (implying that 
there might be multiple header structures), I'd rather avoid it.  I don't 
think this protocol should be so complex as to need multiple definitions; 
there's plenty of room for variability in the layers above and below it.

Scott 

Date: Fri, 02 Apr 2004 16:49:09 -0800
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

At 10:15 AM 4/2/2004 +0100, Stephen Farrell wrote:
>>We do need to address security concerns somehow, but it's not immediately 
>>obvious to me that destination engine ID would give us the best mechanism 
>>for that.
>
>Didn't mean it that way - its just something to be aware of when
>later considering security - a packet from Alice destined for Bob
>could later be replayed at Charlie. The lack of a destination (and
>integrity:-) simply means that Charlie can't always detect this
>easily at the LTP level, and has to depend on lower layers (or
>whatever).

Still thinking about this.  My inclination is indeed to depend on the lower 
layers (data link and physical), as LTP would not be the only 
supra-link-layer protocol affected, but this needs more thought.

>>>>>19. Block ID (7.2.1) If block ID is basically an
>[...]
>>Certainly you could have block ID embedded in the client service data, 
>>and require the client service to insert and extract it.  (Or silently 
>>insert and extract it in the LTP implementation.)  But I don't think it 
>>costs much to expose the thing, especially since you only have to do it 
>>once per block, and I think that simplifies some processing.
>
>Ok. But what processing is simplified? That's what I don't get.

Struggling a bit, myself, to articulate something that has been intuitive 
for me, here's what I come up with:

Block ID has to be conveyed at least once per block of client service data, 
so that the application can know what to do with the block.

A given block might be transmitted in N data segments, but we don't need to 
send block ID N times -- and in fact might prefer not to, which would save 
us some bandwidth.

We don't expose block segmentation to the sending client service.  At the 
same time, we want to give the receiving client service the option to 
receive each data segment's increment of client data as it arrives, rather 
than waiting for delivery of the whole block when it has all been received.

If Block ID were simply (and invisibly, to LTP) provided at the front of 
the client data by the client service, failure to receive the first data 
segment would mean that any incremental client data delivery to the 
receiving client service might be useless.  We need the ability to provide 
Block ID multiple times per block, i.e., in multiple segments.  But 
depending on how clean the link is (how likely we are to lose any single 
segment) we may not want it in every segment; we want to be able to insert 
block ID selectively into some deployment-specific subset of the segments 
generated for any block.  Since segmentation is not exposed to the sending 
client service, the client service can't do this; so LTP has to.  So LTP 
needs to have some place to put Block ID in every data segment, omitting it 
where necessary.

>And if LTP does represent Block ID then we're limiting how the
>higher layer represents that to whatever fits with what the
>encoding rules allow (or lack thereof if we take Leigh's
>approach). Seems like there should be a specific reason to do
>that.
>
>>Let's give this some more thought.
>
>Agreed. First thing I'd do would be to construct a threat model,
>desribing some use cases and listing potential threats for each.
>Maybe you've got something like that lying around? (The use-cases
>part anyway.)

Not a chance.  If you have something at hand, please pass it on.

>[bit errors etc.]
>>Okay, maybe there's some way to make some sort of blanket statement on 
>>this that wouldn't bloat the spec too much.  The basic idea would be that 
>>any invalid value should be interpreted as a bit hit, which should cause 
>>the segment to be discarded immediately without further processing.
>
>So later I'll ask for a resend of that segment's data in an RS?
>(or the sender's timer will expire, or whatever) - Fine so.

Right, whatever happens when a segment simply gets lost in the aether.

>Last part of that was what to do if an entire block goes
>awol - the spec should probably be explicit on that, e.g.
>saying the RS offset=upper bound (=block size) and
>length = 0 or whatever.

I think this is covered, though: the sender's checkpoint timer will 
eventually expire, causing the checkpoint to be retransmitted, causing an 
RS to be returned saying "Please retransmit everything in this block except 
the data that were in that checkpoint segment I just got."

>>Actually ditching the sign bit is fine with me; I'm not wedded to 
>>preserving sign-ability in SDNVs.  But I would still want to preserve the 
>>"+1" weirdness just because it gives us one more doubling of the value 
>>space.  The representations of 65537 would still be 0x82010001; 127 would 
>>now fit into the bottom seven bits of the SDNV's first byte, so as you 
>>say it would be just 0x7F; 255 would still need a second byte, though, so 
>>it would be 0x80FF.  A given SDNV could be a number of up to 256 hex 
>>digits [with a max value of (16**256) - 1]: 128 bytes (2 hex digits 
>>each), preceded by a discriminant byte of 0xFF indicating 127 + 1 
>>additional octets.
>
>That sounds fine to me too.

Excellent.

Scott 

Date: Fri, 2 Apr 2004 16:18:53 -0500
From: Manikantan Ramadas <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

Hi Mr.Farrell,

  Please follow my comments inline :
  
> I like this change, but would like it even more if
> the bits had better names and were changed about
> somewhat - their meaning's are a little opaque to me
> as they stand (probably as a result of how they've
> evolved I'd guess).
> 
> So instead of: Ctrl, E,R,C how about:
> 
> D: Data: set means data, clear means one of RS/RSA/C/CA
> U: Unreliable: set means unreliable, clear means reliable (and
> 	SHOULD be the same for the entire session)
> C: Checkpoint: set means "I want a report, NOW", clear means "no need
> 	to report yet"
> A: Accelerated delivery: set means "please send up to client as you
> 	get bytes in", clear means "do what you want"
> E: EOB: as is
> 
> Does that capture all the combinations? If so, it'd certainly
> be clearer to me (and also de-couples reliability and
> accelerated/deferred delivery, which makes sense IMO). It
> does use an extra bit, but then there's one available.
> 
> What do you think?

  Well the motivation for "Ctrl" bit was exactly the same as what you
propose as the "Data" bit in the flag, but we are just representing
the inverse of it. If the Ctrl bit is 1, it is any kind of control
segment and 0 implies non-control segments which in our case can only
be Data segments. The two are essentially the same. May be calling it
the D/C bit (for Data/Control) might be easier?

  That aside, I have to agree that the bits are not independent of
each other. For example what the E(Exception) bit means depends on
whether it is a Data/Ctrl segment. Similarly the C(Closure) bit's
semantics of what it closes depends on the other bits. It indicates

o EOB when set in a Data segment
o Report ACK if closing a report segment 
o Cancel/ACK if closing a Cancel segment

as you may see from the table in Sec. 7.1.2.

  We argued about this [the fact that the bits are dependent on one
another] before, and decided to postpone discussion on that for later.
May be we should just have 4-bit opcodes? We can have some of the
opcodes undefined in the middle of all 16 possible opcodes, 
if we cared about bit-masking to figure out classes of segments. I
don't know.

 But coming to the interesting argument you make for decoupling
accelerated/deferred delivery from reliable/unreliable delivery.
Clearly, right now LTP does accelerated delivery only
when the block is being transmitted unreliably. A typical example is
when you are transmitting say Telemetry data contiguously and it is
alright if you missed one record as you can make up from subsequent
telemetry records. Do you envision quite some applications that could
use reliable, but out-of-order delivery of segments? May be those
applications should build reliability on top of their own as we see
protocols built on top of UDP that do retransmissions and stuff in the
Internet? What are your thoughts Mr.Burleigh? Others?

> And since I'm making suggestions, how about adding that
> "codec" field (hopefully suggested by Leigh) just after
> the version number in the header? I think that'd justify
> an entire byte or even an SDNV (I could imagine going
> over the 255 values, but you'd probably have rev'd the
> version before that so a byte's enough for now).
> 

  I am not sure what you mean by codecs exactly. Do you envision the
codec field to identify the link protocol below?

Thanks!
Mani.

-- 
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________
  
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

Date: Fri, 2 Apr 2004 10:55:18 -0800
To: Stephen Farrell <[email-masked]>
From: Leigh Torgerson <[email-masked]>
Subject: Re: [dtn-interest] LTP
Cc: [email-masked]
Sender: [email-masked]

Hi Stephen,

I'm just thinking of the advantage of being able to selectively 
tailor the coding and synchronisation functions to suit the physical 
layer at hand.

An upper-layer (sublayer) header to specify which codec might be 
somthing to consider - but on the other hand, I'm not sure how that 
would be used in practice.. right now the TM/TC links work like

[clump of data, happily packaged up in link sublayer to match the 
coding requirements] --> pseudo-randomization to maximize bit 
transitions --> R-S coding --> into the ether ....

if the receiver doesn't already know how to synch up on the symbol 
stream and decode/unrandomize the data, then any header info in the 
[happy clump of data] is moot.

If there was a "switch" sublayer that could use the codec header to 
decide between multiple transmission paths with different codes 
(maybe RS on a long-haul link and convolutional coding on a shorter 
link?), or something like that, maybe a codec header would make sense.

Leigh

>Leigh,
>
>Are you saying that we shouldn't bother about whether SDNV should
>or should not be signed, and similar issues? The problem I'd see
>with that is: who'd care about the purely abstract LTP that'd
>result?
>
>If however, you're saying that there might usefully be some
>early header field which specifies the codec for later fields,
>then that sounds quite reasonable. You can then define a new
>codec later on that suits your lower layers, but still start with
>an LTP that can be implemented and tested, including interop'd.
>
>That could be sort of similar to how SSL/TLS has what it calls
>a "ciphersuite", which is a single byte from a well defined set,
>(values are defined in RFCs) that specifies all sorts of options
>in one go.
>
>Stephen.
>
>Leigh Torgerson wrote:
>>thoughts about "transmission protocol" versus "link protocol" etc.
>>
>><interesting stuff clipped>
>>
>><more interesting stuff clipped - oh shoot - I think I clipped out 
>>what I was going to save..>
>>
>>So anyway:
>>
>>I'm in favor of leaving coding issues aside for the moment...the 
>>current CCSDS link layer specs are broken down into 2 parts now - 
>>sublayers actually - the top sublayer is takes care of the details 
>>of taking packets from above, aggregating them into larger units, 
>>adding headers to keep track of things like virtual channels and 
>>APIDs and so forth. The output of that sublayer is a Transfer Frame.
>>
>>Then the lower sublayer is where the transfer frame is coded up and 
>>put into manageable packages for the physical layer to transmit - 
>>and the packages are designed with physical layer requirements in 
>>mind (i.e. things like idle sequences, fill packets, etc. that make 
>>the hardware design easier/possible, whatever..).
>>
>>There is a lot of detail in the coding and synchronization sublayer 
>>that requires scrutiny of the physical layer characteristics and 
>>noise characteristics of the transmission path. Many coding and 
>>block structure decisions are based on the characteristics of deep 
>>space links and how the DSN stations work, and terrestrial and/or 
>>short-haul radio techniques may not be the best thing in a deep 
>>space environment.
>>
>>At this stage of our LTP planning, I think it might be good to 
>>concentrate on the upper sublayer functionality and postulate what 
>>the coding/synch/physical need to do for us, and then iterate with 
>>the coding and hardware design folks as it becomes more apparent 
>>what we expect out of the coding and physical layer stuff...
>>
>>
>>regards,
>>Leigh

-- 
--------------------------------------------------------------------
J. Leigh Torgerson                           [email-masked]
Jet Propulsion Laboratory - Communications Systems Research Sec. 331
NASA Space Communications Protocol Standards (SCPS) Project CTM
(818) 393-0695                                   (818) 393-4643 fax
--------------------------------------------------------------------

Date: Fri, 02 Apr 2004 16:52:06 +0100
From: Stephen Farrell <[email-masked]>
To: Manikantan Ramadas <[email-masked]>
Cc: Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

Mani,

I like this change, but would like it even more if
the bits had better names and were changed about
somewhat - their meaning's are a little opaque to me
as they stand (probably as a result of how they've
evolved I'd guess).

So instead of: Ctrl, E,R,C how about:

D: Data: set means data, clear means one of RS/RSA/C/CA
U: Unreliable: set means unreliable, clear means reliable (and
	SHOULD be the same for the entire session)
C: Checkpoint: set means "I want a report, NOW", clear means "no need
	to report yet"
A: Accelerated delivery: set means "please send up to client as you
	get bytes in", clear means "do what you want"
E: EOB: as is

Does that capture all the combinations? If so, it'd certainly
be clearer to me (and also de-couples reliability and
accelerated/deferred delivery, which makes sense IMO). It
does use an extra bit, but then there's one available.

What do you think?

And since I'm making suggestions, how about adding that
"codec" field (hopefully suggested by Leigh) just after
the version number in the header? I think that'd justify
an entire byte or even an SDNV (I could imagine going
over the 255 values, but you'd probably have rev'd the
version before that so a byte's enough for now).

Cheers,
Stephen.

Manikantan Ramadas wrote:
> Please follow my comments inline :
> 
> 
>>>15. I believe section 7.1.1 has to contain a bit
>>>which flags for unreliable transport. Or, and maybe
>>>much better, defer that feature until a later version
>>>of the protocol (and figure out how forwards
>>>compatibility could work). Such a bit is IMO better
>>>than the service quality indicator which I at least
>>>find confused/confusing.
>>
>>As it turns out, we could use the Exception bit on all data segments (that 
>>is, segments with Control bit set to zero) to indicate reliable vs 
>>unreliable transport; then the service quality indicator could be dropped.
>>
>>The segment coding scheme got extensively revised a few weeks ago, thanks 
>>to some suggestions from Mani, and I didn't notice this opportunity until 
>>just now.  Mani, any thoughts on this?
>>
> 
> 
>   Yes, we had been battling about doing away with the costly "Service
> Quality Indicator" by stealing up a bit from somewhere to represent
> segments transmitted unreliably. Yes, it would probably be a good idea
> to re-define the table in Section 7.1.2 as follows. It currently has
> the following bit semantics for data-segments :
> 
> 
>    Ctrl  E   R   C   Code  Nature of segment
>    ---- --- --- ---  ----  ---------------------------------------
>      0   0   0   0     0   Data, NOT a Checkpoint, NOT EOB
>      0   0   0   1     1   Data, NOT a Checkpoint, EOB (*)
>      0   0   1   0     2   Data, Checkpoint, NOT EOB
>      0   0   1   1     3   Data, Checkpoint, EOB
> 
>      0   1   0   0     4   Undefined
>      0   1   0   1     5   Undefined
>      0   1   1   0     6   Undefined
>      0   1   1   1     7   Undefined
> 
>      . . . 
>      
>      (*) For unreliable mode only.
>      
>    We can define unreliably transmitted data segments to have the
> Exception bit set in them. But I would suggest we mark Code 0001 as
> undefined [reliably transmitted block should always checkpoint
> its EOB segment] and have the following bit-semantics for data segments :
> 
>    Ctrl  E   R   C   Code  Nature of segment
>    ---- --- --- ---  ----  ---------------------------------------
>      0   0   0   0     0   Data, NOT a Checkpoint, NOT EOB
>      0   0   0   1     1   Undefined
>      0   0   1   0     2   Data, Checkpoint, NOT EOB
>      0   0   1   1     3   Data, Checkpoint, EOB
> 
>      0   1   0   0     4   Data [unreliable transmission], not EOB
>      0   1   0   1     5   Data [unreliable transmission], EOB
>      0   1   1   0     6   Undefined
>      0   1   1   1     7   Undefined
> 
>      . . .
>      
>   We can of course do away with the costly 1 byte Service Quality
> Indicator now, and I like this scheme better. 
> 
> 
>>>7. Section 7, introduction. The bullets sometimes do
>>>and sometimes don't include the abbreviations for the
>>>segment types. Consistency here would be good (though
>>>remembering what Oscar Wilde said about consistency,
>>>feel free to ignore me on this:-)
>>
>>(Emerson, too.)  But I agree.
>>
> 
> 
>   Yeah, I noticed while updating the draft few weeks ago that
> we were using abbreviations and expansions for segment classes quite
> interchangeably throughout, and thought oh well, we can justify my laziness 
> with Emerson's help :-) 
> 
>   But, yeah, I do agree that it would make reading a little-bit
> easier if we introduced abbreviations and used them throughout
> consistently. Can do.
> 
> 
>>>11. Section 8.1. says "must" - did you mean "MUST"? I-Ds
>>>ought to refer to the [MUSTSHOULD] rfc
>>
>>I think so, but I'm pretty ignorant on application of this RFC.  Mani?
> 
> 
>   Infact we do use and refer to the MUSTSHOULD RFC 2119 in our draft.
> I have used it at places in Sections 7 and 9. The only reason I didn't
> use the must keywords for Section 8.1 was that it seemed a little bit
> abstract specification there. But I agree with your argument here.
> Usage of the MUST/SHOULD keywords in Section 8 may be useful. Again, a
> "Can do" here :-)
> 
> - Mani.
> 
> PS : Thanks a lot Mr.Farrell for your patient review!
> 

Date: Fri, 02 Apr 2004 16:36:54 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] more ltp comments
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------080309040500030907040308
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I finished reading the document.

Here're some more comments, mainly on the later parts.

Cheers,
Stephen.

--------------080309040500030907040308
Content-Type: text/plain;
 name="more-ltp.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="more-ltp.txt"

Comments on later sections
==========================

Technical/Bigger
----------------

1. What happens if an LTP engine's queue is full? Say if I normally
queue packets in CF and some inbound packet (part of a reliable delivery)
causes the CF to become full - do I drop the packet and forget I've seen 
it? (And so possibly recover if CF space frees up while I'm playing the 
RS/RSA game with the peer.) Or do I send an immediate "C", or a "C" 
depending on some configuration?

2. I've just noticed that the DS structure means that I only get to
know the overall length of a block when I've gotten all the segments.
Would be not be nice to be able to indicate the overall length earlier
so that the recipient can allocate/reserve resources? If so, then maybe
define a new optional header for this purpose.

3. Asychronous report requesting. I don't think I want to implement this
for my application. Can you (further) explain to me why I'd want it and
in particuilar, how some code would decide when to exercise it? I could
imagine turning it on/off by configuration, but other that anti-DoS
(which is still open) can't see what algorithm (that I care about) 
would decide to suddenly turn on such requests.

4. Checkpoint handling. Taking an example from 9.11, it says, in part:
"This procedure is triggered by either (a) reception of a checkpoint (a
data segment with Request bit set to 1) whose checkpoint serial number
is not equal to that of any previously issued RS segment and whose
service quality indicator is set to 1 (reliable transmission) or (b) an
implementation-specific circumstance pertaining to a particular block
reception session for which no EOB has yet been received ("asynchronous"
reception reporting)."

	Two questions: 
	- can you tell me some "implementation specific circumstance" 
	that'd trigger this? (Maybe this is the same as my previous question 
	above?) [I found one in section 12 - see below]
	- checkpoint serial number (csn) is therefore a counter
	and "not equal..." etc. just means "greater than last csn" or am I
	expected to store all csn's I've seen in a session? Not sure I
	like it very much either way mind you:-() Do we think retransmission
	will be so common that this helps? Presumably, if retransmission were
	very uncommon I could drop the csn idea entirely and just handle
	all report during a session independnently (I think I'd prefer that.)

5. Section 9.11 again. Why can't I handle all reports in the same way as
I handle asychronous ones? The rule about "primary" and "seconday" 
report bounds seems very opaque to me (maybe it'll get clear as I
write code), so I'd expect lots of bugs there implementations. Could
we try to go for the simpler approach? (And even in the "simpler" case,
why do I need to tie the lower bound with the previous "primary" upper
bound? Wouldn't it be enough just to say that you shouldn't leave any
"gaps" in reports?)

6. How do I spot the end of a report segment? I think there's a missing
counter or overall length somewhere since a report segment can have 
any number of offset/length pairs. Maybe I'm just missing something?
(My choice would be to change so that the header contains an overall
length field, but a "number of offset/length pairs" field in the
report segment would also do.)

7. Here's a scenario. Alice sends 3 DS's containing respectively
bytes 0:999, 1000:1999 and 2000:2999 of a 3000 byte long message.
Now say Bob gets the all these, but somehow detects that there
were errors near bytes 1900 and 2100 (just bear with me, don't
say that can't happen for now:-). Can Bob send back a report
to Alice with UB=2999;LB=0;{Off=0;Len=1800};{Off=2200;Len=799}?
And if he does do that, then what should Alice do?
	- Re-Tx DS's 2 & 3 ?
	- Create a new DS containing bytes 1800 to 2199 inclusive?
	- Whichever of those she wants?
[I'd be very much in favor of the last answer there.]

8. section 9.17, 3rd para says:
"It is possible that the Cancel segment is being retransmitted because a
previous Cancel Acknowledgment was lost, in which case there will no
longer be any record of the session of which the segment is one token.
If so, no further action is taken."
How is that (the "no longer ... any record") detected? The sender of 
the CA cannot be assumed to know how many times the peer (who sent 
the C) is willing to retry. Probably I'm confused, but I think I
always have to send a CA when I get a C for a session I know about.

9. How about adding the following guidance (based on how DHCP works,
not an original thought:-). Session IDs are used during sessions,
but sometimes (e.g. the case above) a segment may arrive "just after"
a session has been forgotten. Given that nodes know the latencies
involved, how about adding a recommendation that session IDs should
be maintained for an additional latency+configured period after 
they expire? That'd (probably) allow the right CA to be sent in 
the case above.
The information to be maintained should minimally be the session ID,
but could (at the implemters disgression) include other session 
state (though I'm not sure what's useful right now, if CF isn't 
full-ish and no-one's DoS-ing me, I'd probhaby keep it all for a 
while, and just periodically flush old sessions).

Nits/Quibbles
-------------

1. p42 (9.11, 3rd para) says "As many report segments are produced 
as are required..." 
I think that should be "A report segment is produced containing as 
many offset/length pairs as are required..." (Though maybe that
depends on some of the above technical comments.)

2. 9.13, 3rd para calling this a "countdown timer" is a bit wrong,
isn't this just a re-transmit counter and not really a timer at
all? (Also - the next para talks about releasing buffer space,
which is not appropriate in a protocol specification, other than
as advisory text!)

3. 9.19 says "are" many times, but it could mostly be "can" instead?
In my implementation I think I'll have a periodic garbage collect
rather than release buffers at the 1st opportunity. That shouldn't
be cause for non-conformance.

4. Section 11 implies that a MIB will contain the LTT between
peers. That wouldn't be in a MIB (too much information for SNMP
I'd reckon). Better to just say that relevant, and sufficiently
accurate, ephemeris information needs to be available to the 
nodes.

5. Section 12 mentions CFDP's "immediate" mode and says that's
a special case of asynchronous mode, well that's true, but I'd
have liked this example earlier since it answers a question I
had about whether there were any interesting algorithmic ways
to trigger an asynch. report.

--------------080309040500030907040308--

Resent-Message-Id: <[email-masked]>
Date: Fri, 2 Apr 2004 09:20:45 -0500
From: Manikantan Ramadas <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] LTP
Resent-From: [email-masked]
Resent-Date: Fri, 2 Apr 2004 10:14:53 -0500
Resent-To: [email-masked]
Sender: [email-masked]

Please follow my comments inline :

> >15. I believe section 7.1.1 has to contain a bit
> >which flags for unreliable transport. Or, and maybe
> >much better, defer that feature until a later version
> >of the protocol (and figure out how forwards
> >compatibility could work). Such a bit is IMO better
> >than the service quality indicator which I at least
> >find confused/confusing.
> 
> As it turns out, we could use the Exception bit on all data segments (that 
> is, segments with Control bit set to zero) to indicate reliable vs 
> unreliable transport; then the service quality indicator could be dropped.
> 
> The segment coding scheme got extensively revised a few weeks ago, thanks 
> to some suggestions from Mani, and I didn't notice this opportunity until 
> just now.  Mani, any thoughts on this?
> 

  Yes, we had been battling about doing away with the costly "Service
Quality Indicator" by stealing up a bit from somewhere to represent
segments transmitted unreliably. Yes, it would probably be a good idea
to re-define the table in Section 7.1.2 as follows. It currently has
the following bit semantics for data-segments :

   Ctrl  E   R   C   Code  Nature of segment
   ---- --- --- ---  ----  ---------------------------------------
     0   0   0   0     0   Data, NOT a Checkpoint, NOT EOB
     0   0   0   1     1   Data, NOT a Checkpoint, EOB (*)
     0   0   1   0     2   Data, Checkpoint, NOT EOB
     0   0   1   1     3   Data, Checkpoint, EOB

     0   1   0   0     4   Undefined
     0   1   0   1     5   Undefined
     0   1   1   0     6   Undefined
     0   1   1   1     7   Undefined

     . . . 
     
     (*) For unreliable mode only.
     
   We can define unreliably transmitted data segments to have the
Exception bit set in them. But I would suggest we mark Code 0001 as
undefined [reliably transmitted block should always checkpoint
its EOB segment] and have the following bit-semantics for data segments :

   Ctrl  E   R   C   Code  Nature of segment
   ---- --- --- ---  ----  ---------------------------------------
     0   0   0   0     0   Data, NOT a Checkpoint, NOT EOB
     0   0   0   1     1   Undefined
     0   0   1   0     2   Data, Checkpoint, NOT EOB
     0   0   1   1     3   Data, Checkpoint, EOB

     0   1   0   0     4   Data [unreliable transmission], not EOB
     0   1   0   1     5   Data [unreliable transmission], EOB
     0   1   1   0     6   Undefined
     0   1   1   1     7   Undefined

     . . .
     
  We can of course do away with the costly 1 byte Service Quality
Indicator now, and I like this scheme better. 

> 
> >7. Section 7, introduction. The bullets sometimes do
> >and sometimes don't include the abbreviations for the
> >segment types. Consistency here would be good (though
> >remembering what Oscar Wilde said about consistency,
> >feel free to ignore me on this:-)
> 
> (Emerson, too.)  But I agree.
> 

  Yeah, I noticed while updating the draft few weeks ago that
we were using abbreviations and expansions for segment classes quite
interchangeably throughout, and thought oh well, we can justify my laziness 
with Emerson's help :-) 

  But, yeah, I do agree that it would make reading a little-bit
easier if we introduced abbreviations and used them throughout
consistently. Can do.

> 
> >11. Section 8.1. says "must" - did you mean "MUST"? I-Ds
> >ought to refer to the [MUSTSHOULD] rfc
> 
> I think so, but I'm pretty ignorant on application of this RFC.  Mani?

  Infact we do use and refer to the MUSTSHOULD RFC 2119 in our draft.
I have used it at places in Sections 7 and 9. The only reason I didn't
use the must keywords for Section 8.1 was that it seemed a little bit
abstract specification there. But I agree with your argument here.
Usage of the MUST/SHOULD keywords in Section 8 may be useful. Again, a
"Can do" here :-)

- Mani.

PS : Thanks a lot Mr.Farrell for your patient review!

-- 
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________
  
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

Date: Fri, 2 Apr 2004 09:20:45 -0500
From: Manikantan Ramadas <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

Please follow my comments inline :

> >15. I believe section 7.1.1 has to contain a bit
> >which flags for unreliable transport. Or, and maybe
> >much better, defer that feature until a later version
> >of the protocol (and figure out how forwards
> >compatibility could work). Such a bit is IMO better
> >than the service quality indicator which I at least
> >find confused/confusing.
> 
> As it turns out, we could use the Exception bit on all data segments (that 
> is, segments with Control bit set to zero) to indicate reliable vs 
> unreliable transport; then the service quality indicator could be dropped.
> 
> The segment coding scheme got extensively revised a few weeks ago, thanks 
> to some suggestions from Mani, and I didn't notice this opportunity until 
> just now.  Mani, any thoughts on this?
> 

  Yes, we had been battling about doing away with the costly "Service
Quality Indicator" by stealing up a bit from somewhere to represent
segments transmitted unreliably. Yes, it would probably be a good idea
to re-define the table in Section 7.1.2 as follows. It currently has
the following bit semantics for data-segments :

   Ctrl  E   R   C   Code  Nature of segment
   ---- --- --- ---  ----  ---------------------------------------
     0   0   0   0     0   Data, NOT a Checkpoint, NOT EOB
     0   0   0   1     1   Data, NOT a Checkpoint, EOB (*)
     0   0   1   0     2   Data, Checkpoint, NOT EOB
     0   0   1   1     3   Data, Checkpoint, EOB

     0   1   0   0     4   Undefined
     0   1   0   1     5   Undefined
     0   1   1   0     6   Undefined
     0   1   1   1     7   Undefined

     . . . 
     
     (*) For unreliable mode only.
     
   We can define unreliably transmitted data segments to have the
Exception bit set in them. But I would suggest we mark Code 0001 as
undefined [reliably transmitted block should always checkpoint
its EOB segment] and have the following bit-semantics for data segments :

   Ctrl  E   R   C   Code  Nature of segment
   ---- --- --- ---  ----  ---------------------------------------
     0   0   0   0     0   Data, NOT a Checkpoint, NOT EOB
     0   0   0   1     1   Undefined
     0   0   1   0     2   Data, Checkpoint, NOT EOB
     0   0   1   1     3   Data, Checkpoint, EOB

     0   1   0   0     4   Data [unreliable transmission], not EOB
     0   1   0   1     5   Data [unreliable transmission], EOB
     0   1   1   0     6   Undefined
     0   1   1   1     7   Undefined

     . . .
     
  We can of course do away with the costly 1 byte Service Quality
Indicator now, and I like this scheme better. 

> 
> >7. Section 7, introduction. The bullets sometimes do
> >and sometimes don't include the abbreviations for the
> >segment types. Consistency here would be good (though
> >remembering what Oscar Wilde said about consistency,
> >feel free to ignore me on this:-)
> 
> (Emerson, too.)  But I agree.
> 

  Yeah, I noticed while updating the draft few weeks ago that
we were using abbreviations and expansions for segment classes quite
interchangeably throughout, and thought oh well, we can justify my laziness 
with Emerson's help :-) 

  But, yeah, I do agree that it would make reading a little-bit
easier if we introduced abbreviations and used them throughout
consistently. Can do.

> 
> >11. Section 8.1. says "must" - did you mean "MUST"? I-Ds
> >ought to refer to the [MUSTSHOULD] rfc
> 
> I think so, but I'm pretty ignorant on application of this RFC.  Mani?

  Infact we do use and refer to the MUSTSHOULD RFC 2119 in our draft.
I have used it at places in Sections 7 and 9. The only reason I didn't
use the must keywords for Section 8.1 was that it seemed a little bit
abstract specification there. But I agree with your argument here.
Usage of the MUST/SHOULD keywords in Section 8 may be useful. Again, a
"Can do" here :-)

- Mani.

PS : Thanks a lot Mr.Farrell for your patient review!

-- 
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________
  
* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

Date: Fri, 02 Apr 2004 10:15:53 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

Scott,

[deleting all the "ok then" parts again]

> I don't think you and I are far apart on this (see discussion at bottom 
> of this email), but I'd like to hear what others think.

Ditto.

> We do need to address security concerns somehow, but it's not 
> immediately obvious to me that destination engine ID would give us the 
> best mechanism for that.

Didn't mean it that way - its just something to be aware of when
later considering security - a packet from Alice destined for Bob
could later be replayed at Charlie. The lack of a destination (and
integrity:-) simply means that Charlie can't always detect this
easily at the LTP level, and has to depend on lower layers (or
whatever).

>>>> 19. Block ID (7.2.1) If block ID is basically an
[...]
> Certainly you could have block ID embedded in the client service data, 
> and require the client service to insert and extract it.  (Or silently 
> insert and extract it in the LTP implementation.)  But I don't think it 
> costs much to expose the thing, especially since you only have to do it 
> once per block, and I think that simplifies some processing.

Ok. But what processing is simplified? That's what I don't get.
And if LTP does represent Block ID then we're limiting how the
higher layer represents that to whatever fits with what the
encoding rules allow (or lack thereof if we take Leigh's
approach). Seems like there should be a specific reason to do
that.

> Let's give this some more thought.

Agreed. First thing I'd do would be to construct a threat model,
desribing some use cases and listing potential threats for each.
Maybe you've got something like that lying around? (The use-cases
part anyway.)

[bit errors etc.]
> Okay, maybe there's some way to make some sort of blanket statement on 
> this that wouldn't bloat the spec too much.  The basic idea would be 
> that any invalid value should be interpreted as a bit hit, which should 
> cause the segment to be discarded immediately without further processing.

So later I'll ask for a resend of that segment's data in an RS?
(or the sender's timer will expire, or whatever) - Fine so.

Last part of that was what to do if an entire block goes
awol - the spec should probably be explicit on that, e.g.
saying the RS offset=upper bound (=block size) and
length = 0 or whatever.

> Actually ditching the sign bit is fine with me; I'm not wedded to 
> preserving sign-ability in SDNVs.  But I would still want to preserve 
> the "+1" weirdness just because it gives us one more doubling of the 
> value space.  The representations of 65537 would still be 0x82010001; 
> 127 would now fit into the bottom seven bits of the SDNV's first byte, 
> so as you say it would be just 0x7F; 255 would still need a second byte, 
> though, so it would be 0x80FF.  A given SDNV could be a number of up to 
> 256 hex digits [with a max value of (16**256) - 1]: 128 bytes (2 hex 
> digits each), preceded by a discriminant byte of 0xFF indicating 127 + 1 
> additional octets.

That sounds fine to me too.

Stephen.

Date: Fri, 02 Apr 2004 09:28:50 +0100
From: Stephen Farrell <[email-masked]>
To: Leigh Torgerson <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

Leigh,

Are you saying that we shouldn't bother about whether SDNV should
or should not be signed, and similar issues? The problem I'd see
with that is: who'd care about the purely abstract LTP that'd
result?

If however, you're saying that there might usefully be some
early header field which specifies the codec for later fields,
then that sounds quite reasonable. You can then define a new
codec later on that suits your lower layers, but still start with
an LTP that can be implemented and tested, including interop'd.

That could be sort of similar to how SSL/TLS has what it calls
a "ciphersuite", which is a single byte from a well defined set,
(values are defined in RFCs) that specifies all sorts of options
in one go.

Stephen.

Leigh Torgerson wrote:
> thoughts about "transmission protocol" versus "link protocol" etc.
> 
> <interesting stuff clipped>
> 
> <more interesting stuff clipped - oh shoot - I think I clipped out what 
> I was going to save..>
> 
> So anyway:
> 
> I'm in favor of leaving coding issues aside for the moment...the current 
> CCSDS link layer specs are broken down into 2 parts now - sublayers 
> actually - the top sublayer is takes care of the details of taking 
> packets from above, aggregating them into larger units, adding headers 
> to keep track of things like virtual channels and APIDs and so forth. 
> The output of that sublayer is a Transfer Frame.
> 
> Then the lower sublayer is where the transfer frame is coded up and put 
> into manageable packages for the physical layer to transmit - and the 
> packages are designed with physical layer requirements in mind (i.e. 
> things like idle sequences, fill packets, etc. that make the hardware 
> design easier/possible, whatever..).
> 
> There is a lot of detail in the coding and synchronization sublayer that 
> requires scrutiny of the physical layer characteristics and noise 
> characteristics of the transmission path. Many coding and block 
> structure decisions are based on the characteristics of deep space links 
> and how the DSN stations work, and terrestrial and/or short-haul radio 
> techniques may not be the best thing in a deep space environment.
> 
> At this stage of our LTP planning, I think it might be good to 
> concentrate on the upper sublayer functionality and postulate what the 
> coding/synch/physical need to do for us, and then iterate with the 
> coding and hardware design folks as it becomes more apparent what we 
> expect out of the coding and physical layer stuff...
> 
> 
> regards,
> Leigh
> 

Date: Thu, 1 Apr 2004 15:20:52 -0800
To: [email-masked]
From: Leigh Torgerson <[email-masked]>
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

thoughts about "transmission protocol" versus "link protocol" etc.

<interesting stuff clipped>

<more interesting stuff clipped - oh shoot - I think I clipped out 
what I was going to save..>

So anyway:

I'm in favor of leaving coding issues aside for the moment...the 
current CCSDS link layer specs are broken down into 2 parts now - 
sublayers actually - the top sublayer is takes care of the details of 
taking packets from above, aggregating them into larger units, adding 
headers to keep track of things like virtual channels and APIDs and 
so forth. The output of that sublayer is a Transfer Frame.

Then the lower sublayer is where the transfer frame is coded up and 
put into manageable packages for the physical layer to transmit - and 
the packages are designed with physical layer requirements in mind 
(i.e. things like idle sequences, fill packets, etc. that make the 
hardware design easier/possible, whatever..).

There is a lot of detail in the coding and synchronization sublayer 
that requires scrutiny of the physical layer characteristics and 
noise characteristics of the transmission path. Many coding and block 
structure decisions are based on the characteristics of deep space 
links and how the DSN stations work, and terrestrial and/or 
short-haul radio techniques may not be the best thing in a deep space 
environment.

At this stage of our LTP planning, I think it might be good to 
concentrate on the upper sublayer functionality and postulate what 
the coding/synch/physical need to do for us, and then iterate with 
the coding and hardware design folks as it becomes more apparent what 
we expect out of the coding and physical layer stuff...

regards,
Leigh

-- 
--------------------------------------------------------------------
J. Leigh Torgerson                           [email-masked]
Jet Propulsion Laboratory - Communications Systems Research Sec. 331
NASA Space Communications Protocol Standards (SCPS) Project CTM
(818) 393-0695                                   (818) 393-4643 fax
--------------------------------------------------------------------

Date: Thu, 01 Apr 2004 11:17:37 -0800
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

At 12:56 PM 4/1/2004 +0100, Stephen Farrell wrote:
>[SDNV stuff]
>>Fair enough.  Would it make sense just to use ASN1 instead, on the theory 
>>that there might be existing debugged implementations to
> > leverage?
>
>It does sound better but in the end I don't think it is.
>
>I don't think you really need ASN.1's complexity in this
>protocol. Simply having a length and value should be enough
>since all fields are defined here (and hence are implicitly
>tagged), and as I noted far too often, there's no negative
>number requirement.
>
>I wouldn't object to using the top bit as an indicator of
>a single byte length+value as you did with SDNV. See the
>last nit below for my preferred encoding.
>
>If ASN.1 is the thing to use however, I'd suggest you use
>"OCTET STRING" where that's possible and only use "INTEGER"
>where e.g. you really need a counter. ASN.1 support is widely
>implemented as you say, but you'd probably be getting more
>than you want from any such implementation (e.g. having to
>adopt one of BER/DER/PER or maybe even XER encoding rules;
>or if not potentially having to write rules to disallow
>indefinite length encodings etc). None of the ASN.1 support
>libraries that I know of would easily allow you to just
>link in the bits you really do need.
>
>Finally, ASN.1 handling was recently the cause of a fairly
>major vulnerability in many, many systems (see
>http://www.kb.cert.org/vuls/id/854306 , which is the main
>reason I'm so exercised by SDNV btw).

I don't think you and I are far apart on this (see discussion at bottom of 
this email), but I'd like to hear what others think.

>[DoS stuff]
>
>I think starting a DoS subsection in a security considerations
>section is definitely worth while - even if mounting a DoS
>attack requires the attacker to have their own big antenna,
>(more likely breaching some earthstation firewall), omiting
>such considerations would probably be something that'd be
>regretted later were LTP be a success (and there's no point
>planning for failure:-).

Yep.

>>>7. Unreliable transport.
>[...]
> > The segment coding scheme got extensively revised a few weeks ago,
>
>Sounds better. Can you elaborate on the new scheme?

The revisions are all in the current draft; we haven't changed anything since.

>>>8. LTP as a point-to-point protocol.
>[...]
>>LTP is a point-to-point protocol but it's not a link protocol; it's 
>>designed to live on top of a link protocol, and my first thought would be 
>>that this kind of issue should be sorted out by that protocol.  Is that a 
>>reasonable answer?
>
>I'm not sure really. Are you saying that there's a need then for a
>sub-LTP MAC layer?

Exactly.  In the space communications world, LTP would live on top of CCSDS 
telemetry or telecommand or AOS.

In terrestrial applications I guess it would live on top of PPP, Ethernet, 
etc., but this is not my area of greatest expertise.  I'm lately inclined 
to think of LTP as a non-go-back-N alternative to 802.2 in reliable mode.

>If so, then yes, that gets rid of the issue. If
>not, then it seems like avoiding the problem via scheduling is the
>only easy way out, in which case, the spec should warn about that.
>I guess the reason that scheduling seems to be the only easy way
>out is that there's no "destination engine ID" field in the header
>(or anywhere). [Which may, in principle, raise some other security
>considerations, btw, to do with replay/reflection attacks, even in
>the presence of (some forms of) encryption.]
>
>Maybe adding a destination field would be good. Be interested to
>know why you didn't?

I think mainly because LTP is strictly point-to-point -- it does no routing 
-- so it doesn't have any need to know about destination.

We do need to address security concerns somehow, but it's not immediately 
obvious to me that destination engine ID would give us the best mechanism 
for that.

>>>11. Section 7.1, session ID. What is the temporal
>>>range required for uniqueness?
>[...]
>>Session number is the key concept here, and my inclination is to leave 
>>computation of unique session numbers as an implementation matter.
>
>Yes, but you do need to state the "range" of uniqueness required,
>with the current draft I belive that the session ID has to be
>unique:-
>
>         - for the originator: at any given moment each session ID has
>         to be unique across all potential recipients (the originator
>         could choose to re-use a session ID as soon as the session
>         is completed, either nominally, or as a result of timers
>         expiring)
>
>         - for the recipient: at any given moment, each session ID has
>         only to be unique per originator (i.e. there's no problem if
>         two different originators use the same session ID since the
>         originator engine ID is in the header)
>
>Is that right?

Because the high-order part of session ID is originator, all session IDs 
are universally unique so long as (a) originator engine IDs are unique 
within the communicating subnet [which 4.(1) says must be true] and (b) 
session numbers are unique within originator.  So I think the problem of 
session ID uniqueness just comes down to (b), which I think can be left to 
the implementation.

I think you're talking here about the range of uniqueness of session 
numbers, and I agree that an implementation that reuses session numbers too 
casually is going to be a non-working implementation.  But using as session 
number the concatenation of UNIX time and maybe an 8-bit or 16-bit sequence 
number within timestamp seems like a pretty safe way to avoid that.

>>Timestamp, maybe followed by a sub-sequence number of 8 or 16 bits, seems 
>>like a reasonable choice, but it could be anything; what counts is the 
>>rate at which the LTP engine identified by session originator starts new 
>>block transmission sessions, because it's the concatenation of session 
>>originator ID and session number that has to be unique.  If that rate is 
>>one per minute, a 32-bit timestamp would be plenty, right?
>
>That should almost always work, all I'd ask is that you include an
>example of what does work. A recommendation not to re-use session IDs
>might be good too I guess.

Fair enough.  The draft does say "typically a timestamp", but this could 
certainly be amplified a bit.

>>>12. Engine IDs are in SDNV representation.
>[...]
>>Just to make it a variable-length numeric value.
>
>I much prefer octets for IDs - the structure for numbers
>is unnecessary, and can be misleading (thinking about
>length maxima for octet fields always seems a bit
>different from numeric fields for some reason). I can really
>see wanting to easily map a URI to an engine ID.

Hmmm.  I don't see the problem here: these are just numbers, which happen 
to be expressed in a format that enables them to be variable-length for 
improved bandwidth utilization.  What is the difficulty?

>>>13. Expansion zone [...] What's that for?
>
>>The idea of the expansion zone is just to enable at low cost the 
>>insertion of a few octets of new stuff (that we haven't thought of yet) 
>>without necessarily breaking existing implementations.
>
>And without ramping the version? Can be hard to get that right.
>
>If you are doing this, then a numeric is the wrong type - should
>be just a bunch of octets.

But how many?  The point of using an SDNV is to minimize transmission while 
there is no new stuff, yet avoid screwing up the header parsing in 
implementations when new stuff gets inserted here.

We could lose it, certainly, but it seems to me that it offers a little bit 
of flexibility without costing much.

>[Even more negative number notes...]
>>Not to be argumentative, but I'm not understanding why this is so.  So 
>>long as the number is accurately copied in return traffic, why would we 
>>care whether or not it's negative?
>
>I won't go into details unless you want to, but basically
>you're unnecessarily allowing for more error cases, which
>means I need to write more code, which means more bugs. With
>something so basic, and used so often, I'd rather not have
>to think about that.
>
>Generally, I favour using octets where they work and only
>adding the additional structure of integers where its really
>needed (in this case, for counters, and then I'd wonder
>if you really need 512 bit counters). Strings btw are
>much much worse due to I18N, but luckily you don't have
>that can of worms!

I don't completely follow you, but it's probably moot: I'm happy to ditch 
signed SDNVs if nobody objects (see note at bottom).

>>>19. Block ID (7.2.1) If block ID is basically an
>>>application layer concept, then why's it here at all?
>>>Otherwise, I don't understand how sending zero
>>>instead can be a "local implementation matter"
>>Think of block ID as a supplemental bit of client service data, which 
>>identifies that data.  It's here for the same reason that the client 
>>service data itself is here -- for the convenience of the application.
>
>Not convinced. You do need one of these, but not both. (The block
>ID may be present in the content, but doesn't need to feature
>as an LTP field.) Or is there some way you want to use it to
>prioritise sessions or something?

Certainly you could have block ID embedded in the client service data, and 
require the client service to insert and extract it.  (Or silently insert 
and extract it in the LTP implementation.)  But I don't think it costs much 
to expose the thing, especially since you only have to do it once per 
block, and I think that simplifies some processing.

>>>22. Report serial number (in 7.2.2) is now said to
>>>be a per-session counter starting at zero. That's
>>>guessable, thus potentially allowing easier DoS.
>>>Suggest allowing the 1st one to be random or else
>>>(not as good though) dropping the requirement for
>>>it to be a counter (which isn't currently used,
>>>right? )
>>I think we need a general and comprehensive answer to the DoS question, 
>>which would make this issue moot.
>
>Yes and no. This technique is used to avoid some tcp
>attacks and should work fine here - so this is potentially
>part of a comprehensive anti-DoS approach and is not made
>moot by the fact that there are other anti-DoS considerations.
>(The underlying reason being that we can only add anti-DoS
>measures, we can never "solve" DoS.) [BTW it occurs
>to me now that in this case we might want the report serial
>number to last for more than one session!]

Let's give this some more thought.

>>>23. If I detect a bit error (or other error, say an
>>>unexpected negative number:-) in an rx'd DS header or
>>>in the associated meta-data, but otherwise have no
>>>indication that the client data array is bad - then
>>>what bounds do I use in the RS I send? (As written,
>>>the text just talks about successfully received
>>>data.) Another example - what if everything rx'd
>>>was bad? Do I use Offset=RS-Upper-bound, length=zero
>>>to get everything retransmitted?
>>Excellent point -- this spec doesn't address bit errors at all; we need a 
>>section on services required of the underlying link-layer protocol, which 
>>would say (among other things) that the link layer is responsible for 
>>delivering only error-free frame contents to LTP.
>
>That's fine. But say that the error is a syntax error due to a
>buggy implementation, (say a bad length field) or that, unlikely
>as it may be, some bit errors got through the lower layers (hard to
>credit in the IPN context, but easy to believe in other contexts).
>I think you still have to say how to handle it, since I still have
>to write the handler code.

Okay, maybe there's some way to make some sort of blanket statement on this 
that wouldn't bloat the spec too much.  The basic idea would be that any 
invalid value should be interpreted as a bit hit, which should cause the 
segment to be discarded immediately without further processing.

>>Alternatively we could add CRCs to LTP segments and say that any segment 
>>whose CRC check fails is simply discarded.  I'm kind of partial to 
>>leaving it to the link layers, though, since in many cases they'll 
>>already be doing this.
>
>Different problem. I wasn't asking for a checksum, but for
>the state machine. (Maybe its in the later parts of the spec
>I haven't gotten to yet.)

No, same problem (detecting bit hits and dealing with them somehow), but as 
noted I'm okay with adding some guidance.

>>>13. Section 3.3 says that LTP is unidirectional. While
>>>supporting unidirectional models is definitely
>>>required, I would disagree with failing to offer
>>>support where bidirectional communictions are
>>>possible and since such support is in fact offered
>>>maybe rewording this would be good.
>>
>>Hmmm.  I think this section says what it means to say:[...]
>
>I read it again and it seems better 2nd time round. However,
>it'd be reassuring if it also said something like "though
>LTP sessions are unidirectional, there is nothing to prevent
>simultaneous use of a pair of LTP sessions (one in each
>direction) where the underlying communications layer and
>geometry (e.g. light transit time) allows that".

Sure.

>>>14. SDNV encoding: The "catenating octets 2 through (N+2)
>>>is potentially confusing - can you give an example of how
>>>to encode say "65537" as an SDNV?
>
>>Sure.  65537 is 0x010001; [...] and the SDNV as a whole would be the 
>>4-byte array 0x82010001.
>
>I thought that was it. That "one less than the number of additional
>octets" (giving 0x82) is weird.

Yeah, this is a trick I picked up from CCSDS designs: you'll never have 
zero additional octets, so you can use zero to mean 1 (etc.), increasing by 
1 the maximum octet array length you can accommodate.  Silly in some 
contexts, but here it doubles your potential value space.

>What's 127? Ox81007F - seems strange.

No, just 0x807F.  The first byte is binary 1 (multi-byte value) 0 
(unsigned) 000000 (1 more byte needed) = 0x80; the decimal value 127 is 
0x7F, which fits into the second byte.

>The same value as an ASN.1 INTEGER is DER encoded as "0x0203010001"
>btw - a bit less terse, the DER for zero is "0x0200" again longer
>than necessary in this context. ASN.1 DER encoding also handles the
>sign bit in the value octets and not in the length part, so the
>ASN.1 DER for 255 is 0x020200FF and 0x0201FF is -127. ASN.1 DER can
>handle essentially any length (the top bit of the length field
>is use to indicate a longer length field!).
>
>>But as I say, if there's a better coding scheme that accomplishes the 
>>same purposes I'm happy to go with it.
>
>FWIW "0x83010001" would be my choice (no sign bit) for 65537 and
>"0x7F" for 127, and "0x81FF" for 255.
>
>That's basically SDNV without the sign bit and where the 7 length
>bits in the 1st octet specify the number of octets remaining in
>the value. Works fine for positive integers and octet strings
>up to 8*127 bits long, which I'd say is enough here.

Actually ditching the sign bit is fine with me; I'm not wedded to 
preserving sign-ability in SDNVs.  But I would still want to preserve the 
"+1" weirdness just because it gives us one more doubling of the value 
space.  The representations of 65537 would still be 0x82010001; 127 would 
now fit into the bottom seven bits of the SDNV's first byte, so as you say 
it would be just 0x7F; 255 would still need a second byte, though, so it 
would be 0x80FF.  A given SDNV could be a number of up to 256 hex digits 
[with a max value of (16**256) - 1]: 128 bytes (2 hex digits each), 
preceded by a discriminant byte of 0xFF indicating 127 + 1 additional octets.

>(But not
>enough if you want to do public key crypto sometime - in that
>case you'd need a special set of fields which would not use this
>encoding.)

Which is not an issue, really; representation of crypto keys was only 
mentioned by way of illustration.

Scott 

Date: Thu, 01 Apr 2004 12:56:53 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] LTP
Sender: [email-masked]

Scott,

I deleted stuff where all I'd be saying is "fair enough" (some,
would still be "live" issues though, e.g. some DoS stuff).

[SDNV stuff]
> 
> Fair enough.  Would it make sense just to use ASN1 instead, on the 
> theory that there might be existing debugged implementations to 
 > leverage?

It does sound better but in the end I don't think it is.

I don't think you really need ASN.1's complexity in this
protocol. Simply having a length and value should be enough
since all fields are defined here (and hence are implicitly
tagged), and as I noted far too often, there's no negative
number requirement.

I wouldn't object to using the top bit as an indicator of
a single byte length+value as you did with SDNV. See the
last nit below for my preferred encoding.

If ASN.1 is the thing to use however, I'd suggest you use
"OCTET STRING" where that's possible and only use "INTEGER"
where e.g. you really need a counter. ASN.1 support is widely
implemented as you say, but you'd probably be getting more
than you want from any such implementation (e.g. having to
adopt one of BER/DER/PER or maybe even XER encoding rules;
or if not potentially having to write rules to disallow
indefinite length encodings etc). None of the ASN.1 support
libraries that I know of would easily allow you to just
link in the bits you really do need.

Finally, ASN.1 handling was recently the cause of a fairly
major vulnerability in many, many systems (see
http://www.kb.cert.org/vuls/id/854306 , which is the main
reason I'm so exercised by SDNV btw).

[DoS stuff]

I think starting a DoS subsection in a security considerations
section is definitely worth while - even if mounting a DoS
attack requires the attacker to have their own big antenna,
(more likely breaching some earthstation firewall), omiting
such considerations would probably be something that'd be
regretted later were LTP be a success (and there's no point
planning for failure:-).

>> 7. Unreliable transport.
[...]
 > The segment coding scheme got extensively revised a few weeks ago,

Sounds better. Can you elaborate on the new scheme?

>> 8. LTP as a point-to-point protocol.
[...]
> 
> LTP is a point-to-point protocol but it's not a link protocol; it's 
> designed to live on top of a link protocol, and my first thought would 
> be that this kind of issue should be sorted out by that protocol.  Is 
> that a reasonable answer?

I'm not sure really. Are you saying that there's a need then for a
sub-LTP MAC layer? If so, then yes, that gets rid of the issue. If
not, then it seems like avoiding the problem via scheduling is the
only easy way out, in which case, the spec should warn about that.
I guess the reason that scheduling seems to be the only easy way
out is that there's no "destination engine ID" field in the header
(or anywhere). [Which may, in principle, raise some other security
considerations, btw, to do with replay/reflection attacks, even in
the presence of (some forms of) encryption.]

Maybe adding a destination field would be good. Be interested to
know why you didn't?

>> 11. Section 7.1, session ID. What is the temporal
>> range required for uniqueness? 
[...]
> 
> Session number is the key concept here, and my inclination is to leave 
> computation of unique session numbers as an implementation matter.

Yes, but you do need to state the "range" of uniqueness required,
with the current draft I belive that the session ID has to be
unique:-

	- for the originator: at any given moment each session ID has
	to be unique across all potential recipients (the originator
	could choose to re-use a session ID as soon as the session
	is completed, either nominally, or as a result of timers
	expiring)

	- for the recipient: at any given moment, each session ID has
	only to be unique per originator (i.e. there's no problem if
	two different originators use the same session ID since the
	originator engine ID is in the header)

Is that right?

> Timestamp, maybe followed by a sub-sequence number of 8 or 16 bits, 
> seems like a reasonable choice, but it could be anything; what counts is 
> the rate at which the LTP engine identified by session originator starts 
> new block transmission sessions, because it's the concatenation of 
> session originator ID and session number that has to be unique.  If that 
> rate is one per minute, a 32-bit timestamp would be plenty, right?

That should almost always work, all I'd ask is that you include an
example of what does work. A recommendation not to re-use session IDs
might be good too I guess.

>> 12. Engine IDs are in SDNV representation. 
[...]
> Just to make it a variable-length numeric value.  

I much prefer octets for IDs - the structure for numbers
is unnecessary, and can be misleading (thinking about
length maxima for octet fields always seems a bit
different from numeric fields for some reason). I can really
see wanting to easily map a URI to an engine ID.

>> 13. Expansion zone [...] What's that for? 

> The idea of the expansion zone is just to enable at low cost the 
> insertion of a few octets of new stuff (that we haven't thought of yet) 
> without necessarily breaking existing implementations.  

And without ramping the version? Can be hard to get that right.

If you are doing this, then a numeric is the wrong type - should
be just a bunch of octets.

[Even more negative number notes...]
> Not to be argumentative, but I'm not understanding why this is so.  So 
> long as the number is accurately copied in return traffic, why would we 
> care whether or not it's negative?

I won't go into details unless you want to, but basically
you're unnecessarily allowing for more error cases, which
means I need to write more code, which means more bugs. With
something so basic, and used so often, I'd rather not have
to think about that.

Generally, I favour using octets where they work and only
adding the additional structure of integers where its really
needed (in this case, for counters, and then I'd wonder
if you really need 512 bit counters). Strings btw are
much much worse due to I18N, but luckily you don't have
that can of worms!

>> 19. Block ID (7.2.1) If block ID is basically an
>> application layer concept, then why's it here at all?
>> Otherwise, I don't understand how sending zero
>> instead can be a "local implementation matter" 
> 
> Think of block ID as a supplemental bit of client service data, which 
> identifies that data.  It's here for the same reason that the client 
> service data itself is here -- for the convenience of the application.

Not convinced. You do need one of these, but not both. (The block
ID may be present in the content, but doesn't need to feature
as an LTP field.) Or is there some way you want to use it to
prioritise sessions or something?

>> 20. Offset can't be negative - right? (Oops, I
>> said I'd stop that, didn't I?:-)
> You're right, Stephen, offset cannot be negative.
That's me told then:-) Seriously though - that means
I need to write an extra line of checking code and
have a new error/exception handling branch to test
(or being honest, not test:-).

>> 22. Report serial number (in 7.2.2) is now said to
>> be a per-session counter starting at zero. That's
>> guessable, thus potentially allowing easier DoS.
>> Suggest allowing the 1st one to be random or else
>> (not as good though) dropping the requirement for
>> it to be a counter (which isn't currently used,
>> right? )
> I think we need a general and comprehensive answer to the DoS question, 
> which would make this issue moot.

Yes and no. This technique is used to avoid some tcp
attacks and should work fine here - so this is potentially
part of a comprehensive anti-DoS approach and is not made
moot by the fact that there are other anti-DoS considerations.
(The underlying reason being that we can only add anti-DoS
measures, we can never "solve" DoS.) [BTW it occurs
to me now that in this case we might want the report serial
number to last for more than one session!]

>> 23. If I detect a bit error (or other error, say an
>> unexpected negative number:-) in an rx'd DS header or
>> in the associated meta-data, but otherwise have no
>> indication that the client data array is bad - then
>> what bounds do I use in the RS I send? (As written,
>> the text just talks about successfully received
>> data.) Another example - what if everything rx'd
>> was bad? Do I use Offset=RS-Upper-bound, length=zero
>> to get everything retransmitted?
> 
> Excellent point -- this spec doesn't address bit errors at all; we need 
> a section on services required of the underlying link-layer protocol, 
> which would say (among other things) that the link layer is responsible 
> for delivering only error-free frame contents to LTP.

That's fine. But say that the error is a syntax error due to a
buggy implementation, (say a bad length field) or that, unlikely
as it may be, some bit errors got through the lower layers (hard to
credit in the IPN context, but easy to believe in other contexts).
I think you still have to say how to handle it, since I still have
to write the handler code.

> Alternatively we could add CRCs to LTP segments and say that any segment 
> whose CRC check fails is simply discarded.  I'm kind of partial to 
> leaving it to the link layers, though, since in many cases they'll 
> already be doing this.

Different problem. I wasn't asking for a checksum, but for
the state machine. (Maybe its in the later parts of the spec
I haven't gotten to yet.)

>> 13. Section 3.3 says that LTP is unidirectional. While
>> supporting unidirectional models is definitely
>> required, I would disagree with failing to offer
>> support where bidirectional communictions are
>> possible and since such support is in fact offered
>> maybe rewording this would be good.
> 
> 
> Hmmm.  I think this section says what it means to say:[...]

I read it again and it seems better 2nd time round. However,
it'd be reassuring if it also said something like "though
LTP sessions are unidirectional, there is nothing to prevent
simultaneous use of a pair of LTP sessions (one in each
direction) where the underlying communications layer and
geometry (e.g. light transit time) allows that".

>> 14. SDNV encoding: The "catenating octets 2 through (N+2)
>> is potentially confusing - can you give an example of how
>> to encode say "65537" as an SDNV?

> Sure.  65537 is 0x010001; [...] and the SDNV as a whole would 
> be the 4-byte array 0x82010001.

I thought that was it. That "one less than the number of additional
octets" (giving 0x82) is weird. What's 127? Ox81007F - seems strange.

The same value as an ASN.1 INTEGER is DER encoded as "0x0203010001"
btw - a bit less terse, the DER for zero is "0x0200" again longer
than necessary in this context. ASN.1 DER encoding also handles the
sign bit in the value octets and not in the length part, so the
ASN.1 DER for 255 is 0x020200FF and 0x0201FF is -127. ASN.1 DER can
handle essentially any length (the top bit of the length field
is use to indicate a longer length field!).

> But as I say, if there's a better coding scheme that accomplishes the 
> same purposes I'm happy to go with it.

FWIW "0x83010001" would be my choice (no sign bit) for 65537 and
"0x7F" for 127, and "0x81FF" for 255.

That's basically SDNV without the sign bit and where the 7 length
bits in the 1st octet specify the number of octets remaining in
the value. Works fine for positive integers and octet strings
up to 8*127 bits long, which I'd say is enough here. (But not
enough if you want to do public key crypto sometime - in that
case you'd need a special set of fields which would not use this
encoding.)

You could call that either SDNV+ or SDNV- if you wanted:-)

Cheers,
Stephen.