Hi Fred,

I see I'll need to explain my ATM analogy to the bundle protocol
in a bit more detail.

Please bear with me while I do that and step through some history, before going
into some IETF/CCSDS interaction nuances. (Understanding the needs of the
Consultative Committee for Space Data Systems is key to understanding why the
bundle protocol exists.)

A brief history of ATM

ATM was developed by a single community - telcos with some very restrictive
legacy voice requirements - and passed onto a larger audience as the one true
way to handle true QoS and high-speed switching with Proper Managed
Multiplexing. It had processing performance and other problems, and
was then bypassed by market forces and technical developments, even
though few ever said outright that 'ATM is technically poor'. And it's no
longer used much, even in its core community. Technology has moved on.

Jon Crowcroft's 'J'accuse, ATM' end2end-interest piece from 1994 gives
a flavour of this while it was happening.
https://groups.google.com/forum/#!topic/info.ietf/HCe2X7jzuNY
Daniel Stevenson's 'Electro Political Correctness and High-Speed Networking
or why ATM is Like a Nose,' from the same era, gives more technical detail of
the problems, including the legacy echo cancellation reasons and
compromising that led to that 48-byte payload.

Few actually working on ATM complained much, in public. There were a
number of US research projects, with a number of European research
projects following on after to catch onto what seemed like a good trend.
(Disclaimer of interest: my PhD work was funded by European projects
bringing up the tail end of the ATM infatuation. MPLS seemed like a useful
way out of wholeheartedly committing to anything involving ATM. And
that's why I'm using ATM as the example instead of the earlier OSI stuff.)

ATM was not revised to fix its problems.
The world moved on to better things.


A brief history of the Bundle Protocol

Similarly, the bundle protocol was developed by and for a single community
- NASA-led CCSDS for the 'interplanetary internet' - and passed to a larger
audience as the one true way to handle delay-tolerant networking. (Fall's
2003 SIGCOMM paper was seminal in that; it gave the MANET/ad-hoc crowd
a new focus and banner to wave. Impressive going for a conference paper with
no actual results, widely cited, very influential, and rightly deserving of awards
for being so!)

However, it's sometimes hard to tell a truly useful vision from a momentary
hallucination. "Delay-tolerant networking" soon turned out to be badly scoped,
hence the rise of "disruption-tolerant networking" for the more MANET-ish
and military crowd. DARPA evaluated the bundle protocol, and moved on.
CCSDS and NASA stuck with it.

CCSDS and space agencies are largely resistant to market forces, and slow
to accept technical change; the risks of change are high compared to the
possible rewards. CCSDS is positively risk-friendly compared to people
actually designing for missions. There's also little room for diversity in CCSDS.

CCSDS also has a strong 'not invented here' culture - as an ISO subgroup,
CCSDS even refuses to carry the ISO standard 13239 HDLC. (disclaimer of
interest: we've done some neat things with HDLC from a router in space,
which is why I know enough to make that point as a minor example.)

But then, NASA isn't quite onboard with ISO units of measurement, either.
Hey, ISO's useful - as far as it goes, but not too far. It's nice to be part of a
standards body, but actually commit to using their standards? Really?
Allow HDLC and open the door to layering and IP? No way. In CCSDS,
any layering is an inefficiency, to be designed out. Much engineering
time is spent on this.

Unlike the open-to-everyone IETF, CCSDS is a more closed community
for aerospace - you only get on their mailing lists via space agency
sponsorship, the traditional ISO 'nominated subject matter expert' model.

CCSDS is trapped with a pre-packet processing model, and that needs to change.
CCSDS does not have particularly strong expertise in packetised networking,
which is why SCPS was brought in almost wholesale from TCP/IP in the 1990s
before being modified, and why the IRTF workgroups were set up to help
CCSDS out with the Interplanetary Internet idea; the SIGCCOMM paper
got a lot of people onboard for that. 

CCSDS needs to both outsource the development it can't do that well itself,
and yet control its own destiny and standards, by modifying the results. Those
two goals are somewhat incompatible. So if the IETF were to help CCSDS
out with a standards-track workgroup and do the work to get a published
standard, CCSDS would promptly 'improve' it as was done with SCPS, and
as is currently being done by standardising DTPC, DTNMP and other pieces
around the core bundle protocol, in cooperation with European projects
bringing up the tail end of the DTN movement. (DARPA et al. having
already left the building.) And 'not invented here' becomes 'invented here'
with a CCSDS blue book, which is the kind of thing that e.g. the International
Space Station crowd would be comfortable with.

Given that CCSDS is standardising a whole bunch of pieces that the core
bundle protocol needs, and is restandardising RFC5050 into a blue book,
CCSDS can do the RFC5050bis work as well. Perhaps not as well as the IETF
might if serious IETF effort was brought to bear on it, but the IRTF DTNRG
and RFC5050 already suggests what might result.

It's not as if anyone else other than CCSDS aspires to use the bundle protocol
operationally, so CCSDS may as well own RFC5050bis from the start. And selling
RFC5050bis to the space agencies to adopt is CCSDS's problem.

I don't see an upside for the IETF community in doing this standards work for
CCSDS. And I don't see an upside for the DTN/MANET community, research
or operational, as the bundle protocol restricts innovation by proposing
one homogenous, non-diverse, straitjacket for everyone. Rather as ATM did.

Instead, the world needs to embrace innovation and move on from the
Bundle Protocol.

The bundle protocol is not about connecting different types of internets -
other than IP and CCSDS, what other types of internets are in the picture?
Layering over the top just as IP layered over everything is a  wellmeaning
early idea, nothing more. IP internetworks can be connected using.... IP.
CCSDS has to use IP on the ground, but is strongly resistant to using it
in space. CCSDS is going to have trouble getting missions to accept
layering the bundle protocol over the top of their links. The inefficiencies!
But the bundle protocol is the solution that CCSDS has invested in
heavily.

Given that, I can't see anyone in NASA standing up today and saying 'this bundle
protocol really isn't much good'. Too much would be at stake politically.
It would be like standing up in the 1970s and saying 'I think this side-mounted
solid-booster ceramic-tiled space shuttle is quite unsafe and possibly a rather
bad idea.' The shuttle was the one solution, and that was that. To suggest
otherwise would be a career-limiting moment, going against the tide.
(In hindsight, the problems with the shuttle are now obvious to layman
historians:
http://idlewords.com/2005/08/a_rocket_to_nowhere.htm )

"It is difficult to get a man to understand something,
when his salary depends upon his not understanding it!"
-- Upton Sinclair

Our "A bundle of problems" paper [1] was intended to provide a problem
statement - when it was written, in late 2008, after first attempting to take
the points in it to the research group. We even put 'problems' in the name. 
And most of our problem points were obtained through simple analysis, which
our tests rather predictably bore out. It is now 2014, and in over five years
none of the problems raised have been remedied in the design of the bundle
protocol. Because to do so would be to admit that the bundle protocol is, in fact,
flawed. Rather like ATM, or like the space shuttle.

And the world has moved on from ATM and from the space shuttle.
It didn't try to do them over with a version 2.

[1] http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#bundle-problems
Lloyd Wood, Wesley M. Eddy and Peter Holliday, 'A Bundle of Problems',
IEEE Aerospace Conference, Big Sky, Montana, March 2009.  16 pages.
("the bundle protocol is not technically good"
is just my brief TL;DR summary of those 16 pages.)
http://dx.doi.org/10.1109/AERO.2009.4839384

best regards

Lloyd Wood
http://sat-net.com/L.Wood/dtn/
________________________________________
From: Templin, Fred L <Fred.L.Templin@boeing.com>
Sent: Tuesday, 10 June 2014 1:45 AM
To: Wood L  Dr (Electronic Eng); spencerdawkins.ietf@gmail.com; mls.ietf@gmail.com
Cc: iesg@ietf.org; dtn@ietf.org
Subject: RE: [dtn] DTN BoF Proposal for IETF90

Hi Lloyd,

Responding to your other points:

> CCSDS exerts lockin on space agencies. It's very resistant to market forces (like, you know, TCP/IP),
> and utterly resistant to multiple competing solutions - which is why the bundle protocol was developed
> and pushed. It's rather analogous to the telcos developing ATM in the 1990s to meet their needs, and
> then doing that development in the ATM Forum. The IETF sat happily by, shaking its head for the most
> part.

I don't see it at all that the bundle protocol is analogous to ATM.
ATM was about turning the Internet into "the matrix" - everything
lined up so neat and homogeneous - no room for diversity - an
innovation killer. The Internet is about accommodating diversity,
and we are surely seeing that play out with the way the Internet
has evolved.

DTN (and the bundle protocol) is about interconnecting Internets.
Let each Internet evolve according to its own characteristics, then
hook them up at the edges. BP is all about accommodating diversity.

> The question is, why should the IETF spend further time and effort for CCSDS on the bundle protocol to
> preserve the CCSDS bulwark against IP, where there are other things its experts could be doing that
> benefit actual IETF protocols? The bundle protocol is politically favoured by CCSDS, but is not
> technically good.

I don't understand "preserve the CCSDS bulwark against IP". BP is
designed to connect IP internetworks and uses actual IETF protocols.

Also, "not technically good" is not much of a technical assessment.
You have published "Bundle of Problems", and as I have said it provides
a useful problem statement to build on in a new revision of RFC5050.
Protocols evolve based on insights gained through operational experience;
none of them are perfect in their first iteration.

Thanks - Fred
fred.l.templin@boeing.com