Subject: Re: [dtn-interest] Disruption Tolerant File Systems
From: "Dirk Kutscher" <[email-masked]>
To: "Kevin Fall" <[email-masked]>, "Fred Baker" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Mon, 28 Jun 2010 13:26:17 +0200
List-Id: Delay Tolerant Networking Interest List <dtn-interest.maillists.intel-research.net>

I was about to reply something like that. From some perspective, the bundle protocol -- (as SMTP...) can be viewed as a message-based architecture.

But -- AMQP is rather something in the category of "message-oriented middleware", i.e., application-independent, reliable, interactive messaging (indeed, with some similarities to BEEP).

Whereas the bundle protocol can be used for message-based multi-hop transport (with delay-tolerance...), AMQP is more like a client-server protocol, where message producers connect to a broker that dispatches messages to appropriate subsets of consumers. On top of that, different transaction types are provided, e.g., pub-sub.

Regarding "open specification", well, it seems the AMQP folks have founded an SDO for themselves (www.amqp.org).

Best regards,

Dirk

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Kevin Fall
> Sent: Sunday, June 27, 2010 6:31 PM
> To: Fred Baker
> Cc: [email-masked]; [email-masked];
> <[email-masked]>
> Subject: Re: [dtn-interest] Disruption Tolerant File Systems
> 
> With some of the details aside, the bundle protocol [RFC 5050] is, at
> least to me, a message-based architecture.  Is there some particular
> aspect of "message-based" that isn't captured there?
> 
> - K
> 
> On Jun 26, 2010, at Jun 264:41 PMPDT, Fred Baker wrote:
> 
> > Dumb question. I have been asked to comment on AMQP. To me, a
> message-based architecture would make a *lot* of sense for a delay-
> tolerant architecture. Overlaying that one the basic Internet - would
> that make sense?
> >
> > On Jun 26, 2010, at 1:32 AM, <[email-masked]>
> <[email-masked]> wrote:
> >
> >> A minor note on Scott's terminology. DTN RG can't pursue
> standardization activities, by its very nature as a research group.
> >>
> >> All the RFCs produced by this group (RFC5050, RFC4838, RFC5326 et
> al) are published through the RFC Editor without IESG review, and are
> classified informational or experimental. (Details of the process are
> in RFC5743.)
> >>
> >> This would matter if, say, in CCSDS, one might want to claim that
> RFC5050 et al. are standards worth building on just because they're RFC
> documents and can therefore be normatively referenced in ISO standard
> documents (despite the introductory text in e.g. RFC5050: 'It does not
> specify an Internet standard of any kind.'). They're not standards...
> >>
> >> cheers
> >>
> >> L.
> >>
> >> On 26 Jun 2010, at 00:51, Burleigh, Scott C (313B) wrote:
> >>
> >>> In practice we surely need this sort of thing in many deployments,
> though probably not all.  That is, I think all implementers would be
> glad to see the technology become available, but I'm doubtful that we
> need to pursue it as a standardization activity in DTN RG.
> >>
> >> Lloyd Wood
> >> [email-masked]
> >> http://sat-net.com/L.Wood
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> dtn-interest mailing list
> >> [email-masked]
> >> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> >
> > http://www.ipinc.net/IPv4.GIF
> >
> >
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Mon, 28 Jun 2010 08:56:37 +0200
From: aviana <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] IEEE MASS 2010: Call for Participation and Important Dates for Demos CFP

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

==========================================================================
                          CALL FOR PARTICIPATION

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

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

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

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

CONFERENCE SITE:
----------------
The 7th IEEE International Conference on Mobile Ad-hoc and Sensor 
Systems (IEEE MASS 2010) will be held in San Francisco, California, USA.

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

REGISTRATION:
-------------
Registration to IEEE MASS is now available at the conference website. 
Early registration ends on September 3rd.

WORKSHOPS:
----------
- The Third Workshop on Mobile Entity Localization and Tracking (MELT)
- The Second Workshop on SCEnarios for Network Evaluation Studies (SCENES)
- The Sixth Workshop on Wireless and Sensor Network Security (WSNS)
- The Fourth Workshop on Enabling Technologies and Standards for 
Wireless Mesh Networking (MESHTECH)
- The First BioSense Workshop: Networking and Environmental Sensing meet 
Epidemiology and Biology
- The Second International Workshop on Intelligent Vehicular Networks 
(InVeNet)

CFP DEMOS – IMPORTANT DATES:
----------------------------
Abstract submission deadline:     30 July 2010
Acceptance notification:          27 August 2010
Camera-ready submission:         10 September 2010
IEEE MASS 2010:                  8-12 November 2010

ORGANIZATION COMMITTEE:
-----------------------

GENERAL CO-CHAIRS
Mario Gerla, University of California, Los Angeles
Katia Obraczka, University of California, Santa Cruz

PROGRAM CO-CHAIRS
Guohong Cao, Pennsylvania State University
Prasant Mohapatra, University of California, Davis

TPC SUB-AREA CHAIRS
- Protocols and Cross-Layer Technologies
Ahmed Helmy, University of Florida

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

- Algorithms and theory
Dong Xuan, Ohio State University

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

WORKSHOP CO-CHAIRS
Cedric Westphal, DoCoMo Labs
Christine Pepin, DoCoMo Labs

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

WEB CHAIR
Venkatesh Rajendran, Wionics

FINANCE AND REGISTRATION CHAIR
Zhen Jiang, West Chester University

PUBLICATION CHAIR
Dajin Wang, Montclair State University

PUBLICITY CHAIR
Aline Carneiro Viana, INRIA

LOCAL ARRANGEMENTS CO-CHAIRS
Kumar Viswanath, NTT Labs
Ignacio Solis, PARC

STEERING COMMITTEE CHAIR
Dharma P. Agrawal, University of Cincinnati

CHAIR OF IEEE TC ON DISTRIBUTED PROCESSING
Jie Wu, US National Science Foundation

CHAIR OF IEEE TC ON SIMULATION
Dave Cavalcanti, Phillips Research

From: Kevin Fall <[email-masked]>
Date: Sun, 27 Jun 2010 09:31:18 -0700
To: Fred Baker <[email-masked]>
Cc: [email-masked], [email-masked], "<[email-masked]>" <[email-masked]>
Subject: Re: [dtn-interest] Disruption Tolerant File Systems

With some of the details aside, the bundle protocol [RFC 5050] is, at least to me, a message-based architecture.  Is there some particular aspect of "message-based" that isn't captured there?

- K

On Jun 26, 2010, at Jun 264:41 PMPDT, Fred Baker wrote:

> Dumb question. I have been asked to comment on AMQP. To me, a message-based architecture would make a *lot* of sense for a delay-tolerant architecture. Overlaying that one the basic Internet - would that make sense?
> 
> On Jun 26, 2010, at 1:32 AM, <[email-masked]> <[email-masked]> wrote:
> 
>> A minor note on Scott's terminology. DTN RG can't pursue standardization activities, by its very nature as a research group.
>> 
>> All the RFCs produced by this group (RFC5050, RFC4838, RFC5326 et al) are published through the RFC Editor without IESG review, and are classified informational or experimental. (Details of the process are in RFC5743.)
>> 
>> This would matter if, say, in CCSDS, one might want to claim that RFC5050 et al. are standards worth building on just because they're RFC documents and can therefore be normatively referenced in ISO standard documents (despite the introductory text in e.g. RFC5050: 'It does not specify an Internet standard of any kind.'). They're not standards...
>> 
>> cheers
>> 
>> L.
>> 
>> On 26 Jun 2010, at 00:51, Burleigh, Scott C (313B) wrote:
>> 
>>> In practice we surely need this sort of thing in many deployments, though probably not all.  That is, I think all implementers would be glad to see the technology become available, but I'm doubtful that we need to pursue it as a standardization activity in DTN RG.
>> 
>> Lloyd Wood
>> [email-masked]
>> http://sat-net.com/L.Wood
>> 
>> 
>> 
>> 
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> http://www.ipinc.net/IPv4.GIF
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: <[email-masked]>
To: <[email-masked]>
Date: Sun, 27 Jun 2010 09:03:07 +0100
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Cc: [email-masked], [email-masked]
Subject: [dtn-interest] AMQP was Re:  Disruption Tolerant File Systems

Interesting; hadn't heard of AMQP before.
http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol
http://www.amqp.org/
says it's an open standard (in draft...) - but what's the standards body?

AQMP doesn't really seem message-based; containers communicate via multiplexed sessions that depend on a reliable byte stream with in-order delivery (e.g. TCP). That makes it more suitable for the Internet than for a DTN environment, and the multiplexing should address head-of-line blocking. I'd expect use of sessions to be chatty, despite the asynchronous claim.

AMQP is claimed to run across multiple transports, but they haven't thought about how it would work over UDP. (But its unidirectionality and tying two unidirectional sessions together for bidirectionality would fit with Saratoga.)

The overall framing strikes me as about as useful as BEEP, and in some ways oddly similar.

On 27 Jun 2010, at 00:41, Fred Baker wrote:

> Dumb question. I have been asked to comment on AMQP. To me, a message-based architecture would make a *lot* of sense for a delay-tolerant architecture. Overlaying that one the basic Internet - would that make sense?

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

From: Fred Baker <[email-masked]>
Date: Sat, 26 Jun 2010 16:41:46 -0700
To: "<[email-masked]>" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Disruption Tolerant File Systems

Dumb question. I have been asked to comment on AMQP. To me, a message-based architecture would make a *lot* of sense for a delay-tolerant architecture. Overlaying that one the basic Internet - would that make sense?

On Jun 26, 2010, at 1:32 AM, <[email-masked]> <[email-masked]> wrote:

> A minor note on Scott's terminology. DTN RG can't pursue standardization activities, by its very nature as a research group.
> 
> All the RFCs produced by this group (RFC5050, RFC4838, RFC5326 et al) are published through the RFC Editor without IESG review, and are classified informational or experimental. (Details of the process are in RFC5743.)
> 
> This would matter if, say, in CCSDS, one might want to claim that RFC5050 et al. are standards worth building on just because they're RFC documents and can therefore be normatively referenced in ISO standard documents (despite the introductory text in e.g. RFC5050: 'It does not specify an Internet standard of any kind.'). They're not standards...
> 
> cheers
> 
> L.
> 
> On 26 Jun 2010, at 00:51, Burleigh, Scott C (313B) wrote:
> 
>> In practice we surely need this sort of thing in many deployments, though probably not all.  That is, I think all implementers would be glad to see the technology become available, but I'm doubtful that we need to pursue it as a standardization activity in DTN RG.
> 
> Lloyd Wood
> [email-masked]
> http://sat-net.com/L.Wood
> 
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

http://www.ipinc.net/IPv4.GIF

From: <[email-masked]>
To: <[email-masked]>
Date: Sat, 26 Jun 2010 23:49:58 +0100
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [dtn-interest] Disruption Tolerant File Systems

On 26 Jun 2010, at 14:10, Ray, Robert E. (MSFC-EV43)[JACOBS ENGINEERING GROUP INC] wrote:
> Stephen Farrel wrote:
> 
>> One of the main
>> attractions of the I[ER]TF for me is the willingness to follow the
>> consenus rather than the rulebook,
> 
> On the IETF:
> 
> Actually, I admire the IETF because it is one of the few remaining venues where a solitary voice with a cogent argument can make her point without first having to vet the argument through a phalanx of suits and gasbags.

And that should hold for the IRTF and dtn-interest too.

Unlike, say, the CCSDS sis-dtn mailing list, which has been observed in the past few months to have quietly unsubscribed a number of people able to make such cogent arguments. (Sans any visible notification.)

Given the choice of having a technical discussion about the merits (or otherwise) of the bundle protocol on either sis-dtn or dtn-interest, dtn-interest would be the better, somewhat more informed and inclusive, choice.

> The problem with consensus rises when a piece of work is shaped by corporate or organizational interests.  You may not have seen this in the IRTF/IETF, but when a given model favoring one technological solution over another is championed by a flood of very vocal members from a single chipmaker, to the detriment of other chipmakers and technologies (MCM vs SCM in the case of early VDSL), everyone loses.  It takes a wise bunch to persevere along the intellectually correct course.

This is often seen in the IETF (often when early implementers don't want changes to specifications that require them to re-implement and lose their market edge), but, when I've seen this, it had led to vocal debate (otherwise I wouldn't have noticed it?). Less so with the rapporteur model of other organizations, where input comes down to a decision by one person representing discussion (that can then be overriden by higher-ups).

> 
> That is, someone can state, "You're going about this all wrong", and with an unassailable argument, have a chance to make things right.

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

From: <[email-masked]>
To: <[email-masked]>
Date: Sat, 26 Jun 2010 19:34:16 +0100
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [dtn-interest] Disruption Tolerant File Systems

Ah, you're citing
TierStore: a distributed filesystem for challenged networks in developing regions
Proceedings of the 6th USENIX Conference on File and Storage Technologies, Demmer et al, 2008.

A *distributed* file system is not necessarily a *reliable* file system.

NFS-like semantics using the bundle protocol, which lacks any notion of reliability,
for delivery? A messed-up custody transfer damaging data would go undetected.

I imagine the corruption problems that NFS users experienced running over UDP with
checksums turned off would eventually be rediscovered in Tierstore implementations.

http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8805.mm.www/0179.html
(see also the footnote in Stone's 2000 Sigcomm paper)

plus ça change, plus c'est la même chose.

L.

On 26 Jun 2010, at 16:52, Kevin Fall wrote:

> This may be of interest, if you have't seen it already:
> 
> http://portal.acm.org/citation.cfm?id=1364816
> 
> - K
> 
> 
> On Jun 23, 2010, at Jun 232:20 PMPDT, Ray, Robert E. (MSFC-EV43)[JACOBS ENGINEERING GROUP INC] wrote:
> 
> Hi.
> 
> I had a question that is related to DTN.  It is a pretty simple thought (as it must be to occur to me).
> 
> Since there is active work on Disruption Tolerant Networking, there must also be work on a Disruption Tolerant File System.  That is, store-and-forward needs a way to store.  I presume everyone has always rolled their own variant of the Journaling Flash File System:
> 
> http://en.wikipedia.org/wiki/JFFS
> http://en.wikipedia.org/wiki/JFFS2
> 
> Certainly the JPL wizards have done so repeatedly.  Are there spacecraft-specific variant of these, perhaps?
> 
> Background: I built something like this a few years back in a commercial system because the accountants wouldn't let me put a supercap on the board (I had 10ms after power loss before the power supply was completely gone).  I hindsight, I was implementing something like a TRIM function:
> 
> http://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-for-ssds/
> 
> I ask about this as some guys down the hall are planning to test various FLASH chips on ISS and thought a twofer might be in order.
> 
> Regards,
> Bob Ray
> 
> Robert E. Ray, Jr., Ph.D.
> Advanced Avionics and Processor Systems
> Jacobs/ESTS
> Marshall Space Flight Center
> EV43, Bldg. 4487, Rm B183
> (256) 544-0604 (W)
> 
> "For the good you do is never lost.
> Not even in dreams."
> Pedro Calderon de la Barca
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

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

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Sat, 26 Jun 2010 10:26:48 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Disruption Tolerant File Systems

Quite right, Lloyd; a poor choice of words at the end of a long day.  I wanted the sense of "consensus agreement enabling interoperability", which I think DTNRG is all about and which is indeed not standardization.  Because file system design doesn't seem to me to be a precondition for DTN interoperability I am still doubtful that we need to pursue it on this list, but if there's a sense that it will be a productive direction for research then let's press ahead.

Scott
________________________________________
From: [email-masked] [[email-masked]]
Sent: Saturday, June 26, 2010 1:32 AM
To: Burleigh, Scott C (313B)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn-interest] Disruption Tolerant File Systems

A minor note on Scott's terminology. DTN RG can't pursue standardization activities, by its very nature as a research group.

All the RFCs produced by this group (RFC5050, RFC4838, RFC5326 et al) are published through the RFC Editor without IESG review, and are classified informational or experimental. (Details of the process are in RFC5743.)

This would matter if, say, in CCSDS, one might want to claim that RFC5050 et al. are standards worth building on just because they're RFC documents and can therefore be normatively referenced in ISO standard documents (despite the introductory text in e.g. RFC5050: 'It does not specify an Internet standard of any kind.'). They're not standards...

cheers

L.

On 26 Jun 2010, at 00:51, Burleigh, Scott C (313B) wrote:

> In practice we surely need this sort of thing in many deployments, though probably not all.  That is, I think all implementers would be glad to see the technology become available, but I'm doubtful that we need to pursue it as a standardization activity in DTN RG.

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

From: Kevin Fall <[email-masked]>
Date: Sat, 26 Jun 2010 08:52:38 -0700
To: "Ray, Robert E. (MSFC-EV43)[JACOBS ENGINEERING GROUP INC]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Disruption Tolerant File Systems

--Apple-Mail-15-760131675
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

This may be of interest, if you have't seen it already:

http://portal.acm.org/citation.cfm?id=3D1364816

- K

On Jun 23, 2010, at Jun 232:20 PMPDT, Ray, Robert E. (MSFC-EV43)[JACOBS =
ENGINEERING GROUP INC] wrote:

> Hi.
>=20
> I had a question that is related to DTN.  It is a pretty simple =
thought (as it must be to occur to me).
>=20
> Since there is active work on Disruption Tolerant Networking, there =
must also be work on a Disruption Tolerant File System.  That is, =
store-and-forward needs a way to store.  I presume everyone has always =
rolled their own variant of the Journaling Flash File System:
>=20
> http://en.wikipedia.org/wiki/JFFS
> http://en.wikipedia.org/wiki/JFFS2
>=20
> Certainly the JPL wizards have done so repeatedly.  Are there =
spacecraft-specific variant of these, perhaps?=20
>=20
> Background: I built something like this a few years back in a =
commercial system because the accountants wouldn't let me put a supercap =
on the board (I had 10ms after power loss before the power supply was =
completely gone).  I hindsight, I was implementing something like a TRIM =
function:
>=20
> =
http://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-for=
-ssds/
>=20
> I ask about this as some guys down the hall are planning to test =
various FLASH chips on ISS and thought a twofer might be in order.=20
>=20
> Regards,
> Bob Ray
>=20
> Robert E. Ray, Jr., Ph.D.
> Advanced Avionics and Processor Systems
> Jacobs/ESTS
> Marshall Space Flight Center
> EV43, Bldg. 4487, Rm B183
> (256) 544-0604 (W)
>=20
> "For the good you do is never lost. =20
> Not even in dreams."
> Pedro Calderon de la Barca
>=20
>=20
>=20
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

--Apple-Mail-15-760131675
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">This =
may be of interest, if you have't seen it =
already:<div><br></div><div><span style=3D"visibility: visible;" =
id=3D"main"><span style=3D"visibility:=20
visible;" id=3D"search"><span class=3D"f"><cite><a =
href=3D"http://portal.acm.org/citation.cfm?id=3D1364816">http://portal.acm=
.org/citation.cfm?id=3D1364816</a></cite></span></span></span></div><div><=
i><br></i></div><div><span style=3D"visibility: visible;" =
id=3D"main"><span style=3D"visibility:=20
visible;" id=3D"search"></span></span>- =
K</div><div><br></div><div><br><div><div>On Jun 23, 2010, at Jun 232:20 =
PMPDT, Ray, Robert E. (MSFC-EV43)[JACOBS ENGINEERING GROUP INC] =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>Hi.<br><br>I had a question that is related to DTN. =
&nbsp;It is a pretty simple thought (as it must be to occur to =
me).<br><br>Since there is active work on Disruption Tolerant =
Networking, there must also be work on a Disruption Tolerant File =
System. &nbsp;That is, store-and-forward needs a way to store. &nbsp;I =
presume everyone has always rolled their own variant of the Journaling =
Flash File System:<br><br><a =
href=3D"http://en.wikipedia.org/wiki/JFFS">http://en.wikipedia.org/wiki/JF=
FS</a><br>http://en.wikipedia.org/wiki/JFFS2<br><br>Certainly the JPL =
wizards have done so repeatedly. &nbsp;Are there spacecraft-specific =
variant of these, perhaps? <br><br>Background: I built something like =
this a few years back in a commercial system because the accountants =
wouldn't let me put a supercap on the board (I had 10ms after power loss =
before the power supply was completely gone). &nbsp;I hindsight, I was =
implementing something like a TRIM =
function:<br><br>http://thunk.org/tytso/blog/2009/02/22/should-filesystems=
-be-optimized-for-ssds/<br><br>I ask about this as some guys down the =
hall are planning to test various FLASH chips on ISS and thought a =
twofer might be in order. <br><br>Regards,<br>Bob Ray<br><br>Robert E. =
Ray, Jr., Ph.D.<br>Advanced Avionics and Processor =
Systems<br>Jacobs/ESTS<br>Marshall Space Flight Center<br>EV43, Bldg. =
4487, Rm B183<br>(256) 544-0604 (W)<br><br>"For the good you do is never =
lost. &nbsp;<br>Not even in dreams."<br>Pedro Calderon de la =
Barca<br><br><br><br>_______________________________________________<br>dt=
n-interest mailing =
list<br>[email-masked]<br>http://maillists.inte=
l-research.net/mailman/listinfo/dtn-interest<br></div></blockquote></div><=
br></div></body></html>=

--Apple-Mail-15-760131675--

From: "Ray, Robert E. (MSFC-EV43)[JACOBS ENGINEERING GROUP INC]" <[email-masked]>
To: Stephen Farrell <[email-masked]>, "<[email-masked]>" <[email-masked]>
Date: Sat, 26 Jun 2010 08:10:03 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: Scott C Burleigh <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Disruption Tolerant File Systems

Stephen Farrel wrote:

>One of the main
>attractions of the I[ER]TF for me is the willingness to follow the
>consenus rather than the rulebook,

On the IETF:

Actually, I admire the IETF because it is one of the few remaining venues where a solitary voice with a cogent argument can make her point without first having to vet the argument through a phalanx of suits and gasbags.  The problem with consensus rises when a piece of work is shaped by corporate or organizational interests.  You may not have seen this in the IRTF/IETF, but when a given model favoring one technological solution over another is championed by a flood of very vocal members from a single chipmaker, to the detriment of other chipmakers and technologies (MCM vs SCM in the case of early VDSL), everyone loses.  It takes a wise bunch to persevere along the intellectually correct course.

That is, someone can state, "You're going about this all wrong", and with an unassailable argument, have a chance to make things right.

The above doesn't mean I'm not a gasbag.

Scott Burleigh wrote:

> In practice we surely need this sort of thing in many deployments,
> though probably not all.  That is, I think all implementers would
> be glad to see the technology become available, but I'm doubtful
> that we need to pursue it as a standardization activity in DTN RG.

On DTN and DTFS (disruption-tolerant file system):

I agree that your charter (DTN) does not support file system development.  Nor should it.  But as it appears to be a related subject, at least to me, and since all on this list appear to be quite bright, some rambunctiously so, I thought I would seek a teacher here so that I may learn more and feed my curiosity.  

Regards,
Bob Ray

From: Stephen Farrell <[email-masked]>
To: "<[email-masked]>" <[email-masked]>
Date: Sat, 26 Jun 2010 10:41:21 +0100
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Disruption Tolerant File Systems

On 26 Jun 2010, at 09:32, <[email-masked]> wrote:

> A minor note on Scott's terminology. DTN RG can't pursue  
> standardization activities, by its very nature as a research group.
>
> All the RFCs produced by this group (RFC5050, RFC4838, RFC5326 et  
> al) are published through the RFC Editor without IESG review, and  
> are classified informational or experimental. (Details of the  
> process are in RFC5743.)

Yep. I also wish folks were more careful about this.

> This would matter if, say, in CCSDS, one might want to claim that  
> RFC5050 et al. are standards worth building on just because they're  
> RFC documents and can therefore be normatively referenced in ISO  
> standard documents (despite the introductory text in e.g. RFC5050:  
> 'It does not specify an Internet standard of any kind.'). They're  
> not standards...

Well, CCSDS can and will do what they want, but just because we  
consider these experimental says nothing about how another SDO might  
regard them. There are also always exceptions, e.g. where standards  
track RFCs require informational or whatever. One of the main  
attractions of the I[ER]TF for me is the willingness to follow the  
consenus rather than the rulebook,

S.

>
> cheers
>
> L.
>
> On 26 Jun 2010, at 00:51, Burleigh, Scott C (313B) wrote:
>
>> In practice we surely need this sort of thing in many deployments,  
>> though probably not all.  That is, I think all implementers would  
>> be glad to see the technology become available, but I'm doubtful  
>> that we need to pursue it as a standardization activity in DTN RG.
>
> Lloyd Wood
> [email-masked]
> http://sat-net.com/L.Wood
>
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: <[email-masked]>
To: <[email-masked]>
Date: Sat, 26 Jun 2010 09:32:33 +0100
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [dtn-interest] Disruption Tolerant File Systems

A minor note on Scott's terminology. DTN RG can't pursue standardization activities, by its very nature as a research group.

All the RFCs produced by this group (RFC5050, RFC4838, RFC5326 et al) are published through the RFC Editor without IESG review, and are classified informational or experimental. (Details of the process are in RFC5743.)

This would matter if, say, in CCSDS, one might want to claim that RFC5050 et al. are standards worth building on just because they're RFC documents and can therefore be normatively referenced in ISO standard documents (despite the introductory text in e.g. RFC5050: 'It does not specify an Internet standard of any kind.'). They're not standards...

cheers

L.

On 26 Jun 2010, at 00:51, Burleigh, Scott C (313B) wrote:

> In practice we surely need this sort of thing in many deployments, though probably not all.  That is, I think all implementers would be glad to see the technology become available, but I'm doubtful that we need to pursue it as a standardization activity in DTN RG.

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

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Peter Lovell <[email-masked]>, "Ray, Robert E. (MSFC-EV43)[JACOBS ENGINEERING GROUP INC]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 25 Jun 2010 16:51:33 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Disruption Tolerant File Systems

In practice we surely need this sort of thing in many deployments, though probably not all.  That is, I think all implementers would be glad to see the technology become available, but I'm doubtful that we need to pursue it as a standardization activity in DTN RG.

Scott

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Peter Lovell
> Sent: Wednesday, June 23, 2010 5:12 PM
> To: Ray, Robert E. (MSFC-EV43)[JACOBS ENGINEERING GROUP INC]; dtn-
> [email-masked]
> Subject: Re: [dtn-interest] Disruption Tolerant File Systems
> 
> On Wed, Jun 23, 2010, Ray, Robert E. (MSFC-EV43)[JACOBS ENGINEERING
> GROUP INC] <[email-masked]> wrote:
> 
> >Hi.
> >
> >I had a question that is related to DTN.  It is a pretty simple thought
> >(as it must be to occur to me).
> >
> >Since there is active work on Disruption Tolerant Networking, there must
> >also be work on a Disruption Tolerant File System.  That is, store-and-
> >forward needs a way to store.  I presume everyone has always rolled
> >their own variant of the Journaling Flash File System:
> >
> >http://en.wikipedia.org/wiki/JFFS
> >http://en.wikipedia.org/wiki/JFFS2
> >
> >Certainly the JPL wizards have done so repeatedly.  Are there spacecraft-
> >specific variant of these, perhaps?
> >
> >Background: I built something like this a few years back in a commercial
> >system because the accountants wouldn't let me put a supercap on the
> >board (I had 10ms after power loss before the power supply was
> >completely gone).  I hindsight, I was implementing something like a TRIM
> >function:
> >
> >http://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-
> >for-ssds/
> >
> >I ask about this as some guys down the hall are planning to test various
> >FLASH chips on ISS and thought a twofer might be in order.
> >
> >Regards,
> >Bob Ray
> 
> 
> Hi Bob,
> 
> I have suggested this a time or two, especially as regards security-
> protocol pieces associated with a payload. As it is right now, those
> blocks exist only for the time that a bundle is in transit and not when
> it is stored in a searchable repository, or whatever.
> 
> There are certainly many tactical military uses for this, beside the
> space-based ones.
> 
> For reasons of simplicity, I have deliberately held back from defining a
> file system and have limited the scope of my ideas to a file format that
> could reside in various file systems. That's much the same as dtn bundle
> traveling across various transport layers, such as TCP/IP, Bluetooth,
> snowmobile and so on.
> 
> If you really need a file system then maybe our ideas are complementary.
> 
> Cheers.....Peter
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Kevin Fall <[email-masked]>
Date: Thu, 24 Jun 2010 15:11:54 -0700
To: [email-masked]
Subject: Re: [dtn-interest] DTNRG session slot at IETF 78 (update)

--Apple-Mail-14-610087771
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

hmm, now I am told we will get *2* slots, so that means we'll have 2 =
hours allocated, starting at 1300.  go figure :o.
Room:  Berlin/Copenhagen

- K

On Jun 24, 2010, at Jun 243:01 PMPDT, Kevin Fall wrote:

>=20
> Our allocation is Friday 1300-1400.  I had requested 1.5 hours, but we =
got assigned just the one hour.  There are many requests for slots this =
IETF, which I assume is the reason for the reduction.
>=20
> - K
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

--Apple-Mail-14-610087771
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">hmm, =
now I am told we will get *2* slots, so that means we'll have 2 hours =
allocated, starting at 1300. &nbsp;go figure :o.<div>Room: &nbsp;<span =
class=3D"Apple-style-span" style=3D"font-family: Consolas; font-size: =
11px; ">Berlin/Copenhagen</span></div><div><font =
class=3D"Apple-style-span" face=3D"Consolas" size=3D"3"><span =
class=3D"Apple-style-span" style=3D"font-size: =
11px;"><br></span></font><div><br></div><div>- =
K</div><div><br><div><div>On Jun 24, 2010, at Jun 243:01 PMPDT, Kevin =
Fall wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div><br>Our allocation is Friday 1300-1400. &nbsp;I had =
requested 1.5 hours, but we got assigned just the one hour. &nbsp;There =
are many requests for slots this IETF, which I assume is the reason for =
the reduction.<br><br>- =
K<br>_______________________________________________<br>dtn-interest =
mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br>http://maillists.intel-research.net/mailm=
an/listinfo/dtn-interest<br></div></blockquote></div><br></div></div></bod=
y></html>=

--Apple-Mail-14-610087771--

From: Kevin Fall <[email-masked]>
Date: Thu, 24 Jun 2010 15:01:21 -0700
To: [email-masked]
Subject: [dtn-interest] DTNRG session slot at IETF 78

Our allocation is Friday 1300-1400.  I had requested 1.5 hours, but we got assigned just the one hour.  There are many requests for slots this IETF, which I assume is the reason for the reduction.

- K

From: Peter Lovell <[email-masked]>
To: "Ray, Robert E. (MSFC-EV43)[JACOBS ENGINEERING GROUP INC]" <[email-masked]>, [email-masked]
Date: Wed, 23 Jun 2010 20:12:14 -0400
Subject: Re: [dtn-interest] Disruption Tolerant File Systems

On Wed, Jun 23, 2010, Ray, Robert E. (MSFC-EV43)[JACOBS ENGINEERING
GROUP INC] <[email-masked]> wrote:

>Hi.
>
>I had a question that is related to DTN.  It is a pretty simple thought
>(as it must be to occur to me).
>
>Since there is active work on Disruption Tolerant Networking, there must
>also be work on a Disruption Tolerant File System.  That is, store-and-
>forward needs a way to store.  I presume everyone has always rolled
>their own variant of the Journaling Flash File System:
>
>http://en.wikipedia.org/wiki/JFFS
>http://en.wikipedia.org/wiki/JFFS2
>
>Certainly the JPL wizards have done so repeatedly.  Are there spacecraft-
>specific variant of these, perhaps?
>
>Background: I built something like this a few years back in a commercial
>system because the accountants wouldn't let me put a supercap on the
>board (I had 10ms after power loss before the power supply was
>completely gone).  I hindsight, I was implementing something like a TRIM
>function:
>
>http://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-
>for-ssds/
>
>I ask about this as some guys down the hall are planning to test various
>FLASH chips on ISS and thought a twofer might be in order.
>
>Regards,
>Bob Ray

Hi Bob,

I have suggested this a time or two, especially as regards security-
protocol pieces associated with a payload. As it is right now, those
blocks exist only for the time that a bundle is in transit and not when
it is stored in a searchable repository, or whatever.

There are certainly many tactical military uses for this, beside the
space-based ones.

For reasons of simplicity, I have deliberately held back from defining a
file system and have limited the scope of my ideas to a file format that
could reside in various file systems. That's much the same as dtn bundle
traveling across various transport layers, such as TCP/IP, Bluetooth,
snowmobile and so on.

If you really need a file system then maybe our ideas are complementary.

Cheers.....Peter

From: "Ray, Robert E. (MSFC-EV43)[JACOBS ENGINEERING GROUP INC]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 23 Jun 2010 16:20:38 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Disruption Tolerant File Systems

Hi.

I had a question that is related to DTN.  It is a pretty simple thought (as it must be to occur to me).

Since there is active work on Disruption Tolerant Networking, there must also be work on a Disruption Tolerant File System.  That is, store-and-forward needs a way to store.  I presume everyone has always rolled their own variant of the Journaling Flash File System:

http://en.wikipedia.org/wiki/JFFS
http://en.wikipedia.org/wiki/JFFS2

Certainly the JPL wizards have done so repeatedly.  Are there spacecraft-specific variant of these, perhaps? 

Background: I built something like this a few years back in a commercial system because the accountants wouldn't let me put a supercap on the board (I had 10ms after power loss before the power supply was completely gone).  I hindsight, I was implementing something like a TRIM function:

http://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-for-ssds/

I ask about this as some guys down the hall are planning to test various FLASH chips on ISS and thought a twofer might be in order. 
 
Regards,
Bob Ray

Robert E. Ray, Jr., Ph.D.
Advanced Avionics and Processor Systems
Jacobs/ESTS
Marshall Space Flight Center
EV43, Bldg. 4487, Rm B183
(256) 544-0604 (W)

"For the good you do is never lost.  
Not even in dreams."
Pedro Calderon de la Barca

From: Kevin Fall <[email-masked]>
Date: Wed, 23 Jun 2010 09:57:45 -0700
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] Maastricht meeting - who is coming?

ok great.

I don't yet have the date assignment... possibly tomorrow.  Will post once I know.

thx,
- K

On Jun 23, 2010, at Jun 237:41 AMPDT, Elwyn Davies wrote:

> A representative (or possibly two) of the PRoPHET authors are
> considering coming.  We have some updates on the PRoPHET work which we
> would like to present - improved equations and a solution to the parking
> lot problem that has been bugging us for a long time.
> 
> Do you have any handle on what day the meeting is likely to be? Both of
> the possible attendees are in Europe and don't need or aren't able to be
> in Maastricht for the whole week.
> 
> Regards,
> Elwyn
> 
> Kevin Fall wrote:
>> I have reserved a 1.5-hr DTNRG slot at Maastricht.  Could I get a sense of which DTNRG folks are planning to attend?
>> Also, if you would like to present something, please let us know.
>> 
>> thx,
>> - K
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> 
> 

Date: Wed, 23 Jun 2010 15:41:23 +0100
From: Elwyn Davies <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Maastricht meeting - who is coming?
Reply-To: [email-masked]

A representative (or possibly two) of the PRoPHET authors are
considering coming.  We have some updates on the PRoPHET work which we
would like to present - improved equations and a solution to the parking
lot problem that has been bugging us for a long time.

Do you have any handle on what day the meeting is likely to be? Both of
the possible attendees are in Europe and don't need or aren't able to be
in Maastricht for the whole week.

Regards,
Elwyn

Kevin Fall wrote:
> I have reserved a 1.5-hr DTNRG slot at Maastricht.  Could I get a sense of which DTNRG folks are planning to attend?
> Also, if you would like to present something, please let us know.
>
> thx,
> - K
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>   

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Markus Doerge <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 21 Jun 2010 09:04:30 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Fragmentation in dtn2

In DTN2 we have done proactive and reactive fragmentation.  Reactive was purely by accident but work.  Also, reactive was using the TCP convergence layer.
http://mailman.dtnrg.org/pipermail/dtn-interest/2009-October/004228.html

I also posted a draft of a paper submitted go Globcom 2010.  I believe acceptance/rejection is July 2010.
http://roland.grc.nasa.gov/~ivancic/papers_presentations/2010/Large-File%20Transfers%20from%20Space%20Using%20Multiple%20Ground%20Terminals%20and%20Delay%20Tolerant%20Networking_R1.pdf

Note well, reactive fragmentation and DTN security such as bundle authentication block are currently mutually exclusive.  This is also the case for reliability if it were ever to be implemented (CRC).  I believe much more thought needs to go into the design to figure out and decide what is the best mode of operations regarding reactive fragmentation.  It is certainly useful.

I posted my IRTF presentation here as the DTNRG meeting slides for the meeting held at IETF-77 do not appear to be posted.
http://roland.grc.nasa.gov/~ivancic/papers_presentations/2010/DTNRG-IETF77-ReactiveFragmentation-Ivancic-Final.pdf

--Will

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Markus
>Doerge
>Sent: Monday, June 21, 2010 7:26 AM
>To: [email-masked]
>Subject: [dtn-interest] Fragmentation in dtn2
>
>Hi all,
>
>is the fragmentation (proactive and reactive) fully supported in the
>dtn2 implementation?
>
>Best regards,
>Markus
>--

Date: Mon, 21 Jun 2010 13:25:38 +0200
From: "Markus Doerge" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Fragmentation in dtn2

Hi all,

is the fragmentation (proactive and reactive) fully supported in the dtn2 implementation?

Best regards,
Markus
-- 
GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl.  
Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl

From: Kevin Fall <[email-masked]>
Date: Sun, 13 Jun 2010 23:04:15 -0700
To: [email-masked]
Subject: [dtn-interest] Maastricht meeting - who is coming?

I have reserved a 1.5-hr DTNRG slot at Maastricht.  Could I get a sense of which DTNRG folks are planning to attend?
Also, if you would like to present something, please let us know.

thx,
- K

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 11 Jun 2010 13:37:00 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] version 2.2.0 of ION is available

Hi.  ION v.2.2.0 has now been posted to http://www.openchannelfoundation.org/projects/ION/.  No major changes, but a couple of new features and some bug fixes; see the Release Notes at http://www.openchannelfoundation.org/project/view_user_defined_page.php?user_defined_page_id=3353&group_id=381 for details.

Scott

Date: Wed, 09 Jun 2010 12:56:16 +0200
From: aviana <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] IEEE MASS 2010: Call for Participation and Important Dates for Workshops and Demos CFP

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

==========================================================================
	   	         CALL FOR PARTICIPATION

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

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

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

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

CONFERENCE SITE:
----------------
The 7th IEEE International Conference on Mobile Ad-hoc and Sensor 
Systems (IEEE MASS 2010) will be held in San Francisco, California, USA.

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

REGISTRATION:
-------------
Registration to IEEE MASS is now available at the conference website. 
Early registration ends on September 3rd.

WORKSHOPS:
----------
- The Third Workshop on Mobile Entity Localization and Tracking (MELT)
- The Second Workshop on SCEnarios for Network Evaluation Studies (SCENES)
- The Sixth Workshop on Wireless and Sensor Network Security (WSNS)
- The Fourth Workshop on Enabling Technologies and Standards for 
Wireless Mesh Networking (MESHTECH)
- The First BioSense Workshop: Networking and Environmental Sensing meet 
Epidemiology and Biology
- The Second International Workshop on Intelligent Vehicular Networks 
(InVeNet)

CFP WORKSHOPS - IMPORTANT DATES:
--------------------------------
Manuscripts due: 			June 18, 2010
Acceptance notification: 	August 13, 2010
Camera-ready submission:      September 3, 2010

CFP DEMOS – IMPORTANT DATES:
----------------------------
Abstract submission deadline: 	30 July 2010
Acceptance notification: 	27 August 2010
Camera-ready submission:	10 September 2010
IEEE MASS 2010: 		8-12 November 2010

ORGANIZATION COMMITTEE:
-----------------------

GENERAL CO-CHAIRS
Mario Gerla, University of California, Los Angeles
Katia Obraczka, University of California, Santa Cruz

PROGRAM CO-CHAIRS
Guohong Cao, Pennsylvania State University
Prasant Mohapatra, University of California, Davis

TPC SUB-AREA CHAIRS
- Protocols and Cross-Layer Technologies
Ahmed Helmy, University of Florida

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

- Algorithms and theory
Dong Xuan, Ohio State University

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

WORKSHOP CO-CHAIRS
Cedric Westphal, DoCoMo Labs
Christine Pepin, DoCoMo Labs

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

WEB CHAIR
Venkatesh Rajendran, Wionics

FINANCE AND REGISTRATION CHAIR
Zhen Jiang, West Chester University

PUBLICATION CHAIR
Dajin Wang, Montclair State University

PUBLICITY CHAIR
Aline Carneiro Viana, INRIA

LOCAL ARRANGEMENTS CO-CHAIRS
Kumar Viswanath, NTT Labs
Ignacio Solis, PARC

STEERING COMMITTEE CHAIR
Dharma P. Agrawal, University of Cincinnati

CHAIR OF IEEE TC ON DISTRIBUTED PROCESSING
Jie Wu, US National Science Foundation

CHAIR OF IEEE TC ON SIMULATION
Dave Cavalcanti, Phillips Research

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 1 Jun 2010 15:15:04 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] revised ECOS I-D

The Internet Draft for the Extended Class of Service block was going to expire on Sunday, so I have reposted it.  The draft now includes one additional class-of-service flag that I think will be needed in some environments with extremely asymmetrical data rates.

The flag turns on a feature that is in some ways similar to hop-by-hop custody transfer except that the custody acceptance and refusal signals are implicit rather than explicit: custody transfer is *not* requested for the bundle, and the convergence-layer adapter simulates a pseudo-custodial acceptance when convergence-layer transmission of the bundle succeeds and a pseudo-custodial refusal when convergence-layer bundle transmission fails.

This enables behavior similar to Custody Transfer Failure procedures (e.g., reforwarding, rerouting) to be initiated as needed without incurring the return-link overhead of custody acceptance signals for all bundles that are successfully transmitted.  The main effect of the flag is to attach an additional retention constraint to the bundle, to prevent it from being discarded immediately upon removal of the "forward pending" constraint.

Scott