Fred,

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.

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.

(Also, it's unclear, from this discussion, that when you say 'a standard' whether you mean 'a published RFC' or 'a standards-track RFC' or 'a standard'. Those are progressively higher bars.)

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Templin, Fred L <Fred.L.Templin@boeing.com>
Sent: Friday, 6 June 2014 4:02 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,

Wading through your points, you seem to be concerned that standardizing
the Bundle Protocol in the IETF will somehow block other approaches from
going forward in the future, but that would not be consistent with my
understanding of the way the IETF operates. There are many examples where
multiple solutions for roughly the same problem space have gone forward
to standards track and have all found widespread application - sometimes
based on the best-fit solution for the particular problem and sometimes
based on market forces.

The purpose of having a standard is so that vendors can independently
create interoperable implementations, and the IETF is the correct forum
for developing internetworking standards.

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

> -----Original Message-----
> From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of l.wood@surrey.ac.uk
> Sent: Thursday, June 05, 2014 4:20 AM
> To: spencerdawkins.ietf@gmail.com; mls.ietf@gmail.com
> Cc: iesg@ietf.org; dtn@ietf.org
> Subject: Re: [dtn] DTN BoF Proposal for IETF90
>
> As previously expressed on DTNRG, I have a number of concerns about
> this proposed BOF to create an IETF DTN WG to do work on the
> RFC5050 bundle protocol, produced in the IRTF DTNRG, and create
> an RFC5050bis. I'll go through those concerns one by one:
>
>
> 1. I don't see how going standards track can be justified, because:
>
>    a. CCSDS is already working on the bundle protocol as one of their
>       blue book standards, based on RFC5050, and any RFC5050bis
>       would presumably also be adopted and then modified to make
>       a CCSDS standard.
>       It's rather like CCSDS restandardizing TCP/IP as SCPS, back
>       in the 1990s. That SCPS standardization wasn't used much
>       either, not least because CCSDS 'improved' on TCP/IP
>       and went incompatible quite quickly. The same will happen
>       with the CCSDS bundle protocol, and in adopting RFC5050
>       CCSDS has reserved the right to make changes - things like
>       Delay Tolerant Payload Conditioning (DTPC) are but the start.
>       There's an example of bundle protocol work not requiring
>       the IETF. Work on altering and extending the bundle protocol
>       is already ongoing in CCSDS.
>       Setting up an IETF workgroup to work in parallel would mean
>       that a CCSDS liaison would be required, to pay attention
>       to their concerns as they try and convince their member space
>       agencies to use the bundle protocol, and to prevent their spec
>       from diverging (further) from the IETF spec. Really, the work
>       is simply more easily done in CCSDS, given that CCSDS is
>       pretty much the only customer for bundle protocol, because
>       NASA has mandated bundle protocol use from on high.
>       NASA leads CCSDS, NASA Jet Propulsion Lab leads CCSDS design
>       for NASA's Space Communications and Navigation people.
>       JPL is really the primary customer for and user of bundle
>       protocol, responsible for promoting its use by other space
>       agencies - never an easy task, even with good technologies.
>
>    b. The IETF produces Internet standards. The bundle protocol
>       has little bearing on or interaction with Internet standards;
>       it's arguably a way to interoperate with the Internet while
>       protecting CCSDS from incursion of the Internet, by layering
>       over both Internet and CCSDS. Each to their own domains.
>       Using TCP as the most common bundle convergence layer (described
>       in a draft now seven years old) does not make the bundle protocol
>       an internet standard. If it did, then CCSDS's Space Link
>       Extension (basically a TCP tunnel carrying CCSDS frames, with
>       much added complexity) would also be a candidate for an
>       IETF internet standard.
>       But, again, that work is best done in CCSDS, where there
>       is interest in having it done and there are users. (Some
>       of those users may even be willing users.)
>
>    c. The bundle protocol is not mature. Deficiencies have been
>       identified, drafts have been written in DTNRG over the years,
>       there was little interest, the drafts expired, the bundle
>       protocol was never improved. And that's just from demonstrations;
>       there has not been extended operational use to my knowledge.
>       Attempting to fix the bundle protocol AND push it through as
>       standards track at the same time seems unwarranted.
>       It may be politically motivated, but it is
>       not technically or procedurally justifiable.
>       There isn't the userbase or demand needed for the bundle
>       protocol to go standards track, and if the IETF did go
>       standards track, CCSDS would 'optimize' that standard into
>       its own standard, just as was done with SCPS, meaning that
>       the IETF would spend a lot of time working on something with
>       no benefit to the IETF community or userbase. Extending
>       the Internet protocols to the DTN network problem space
>       adds value to the internet protocols. A separate protocol
>       does not.
>       Who would benefit, outside the CCSDS community? And CCSDS
>       is their own standards org - an ISO subgroup - to do work
>       for that CCSDS community.
>
>
> 2. I don't see why this needs to be done in an IETF WG, because:
>
>    a. going standards track isn't justifiable - see 1.
>
>    b. There's already the IRTF DTNRG, which could clean up its
>       own work, but ,after many years and some failed drafts,
>       has not.
>       Declaring success and saying it is now time to create a
>       WG based on DTNRG's achievements is not convincing,
>       because those achievements are not impressive.
>       (Disclaimer of interest: I authored 'A bundle of problems'
>       and have spent considerable years trying to explain and
>       address problems with the bundle protocol, with little
>       success, after getting it tested in space before NASA's
>       EXPOXI/Deep Impact tests took place.
>       Fred Templin's problem statement drafts for this putative
>       IETF BOF calls on that work.)
>       RFC5050bis would make more sense as a DTNRG
>       effort, though it would be time for a changing of the
>       guard and chairs in DTNRG to infuse some new blood and
>       technical judgement - or we're in for another five years
>       of what-does-the-end-to-end-principle-really-mean and
>       what-about-clocks and rehashing the same old arguments.
>       Really, DTNRG needs to get its act together, both
>       organizationally and technically.
>
>    c. There's already CCSDS, which has adopted the DTNRG output,
>       after pushing for the formation of an Interplanetary
>       Internet RG in the first place.
>
> So either CCSDS or DTNRG can do RFC5050 revision work. If
> it's to be an RFC, experimental or informational, a revitalised
> rechartered DTNRG can do it.
> It doesn't need to be an IETF workgroup. It certainly
> shouldn't go standards track.
>
>
> 3. The philosophically shaky basis for the bundle protocol:
>
>    a. Delay-tolerant networking is not disruption-tolerant
>       networking. Space delays of light-minutes with scheduled
>       contacts are not the same as intermittent ad-hoc
>       manet-style communications. Different requirements,
>       different buffering and storage, different conditions,
>       different handling of fragmentation, etc.
>
>    b. The bundle protocol is not DTN. DTN is the scenario,
>       in which other approaches (the related CFDP, Haggle,
>       the MANET and vehicular DTNs efforts that DTN subsumed
>       and rebranded, etc.) exist.
>       The bundle protocol is intended to be used in a DTN
>       scenario. Branding the bundle protocol as DTN has
>       put back non-bundle DTN research a number of years.
>       Branding a group only working on the bundle protocol
>       as 'DTN' is misleading at best.
>
>    c. Extending the bundle protocol from the original
>       Interplanetary Internet problem (which had its own
>       IRTF RG which led into a set bundle agenda for
>       DTNRG) to cover everything else as well simply hasn't
>       worked very well, because the scenarios and use cases
>       are different. We design for use cases. To be too
>       generalised is to engineer for nothing.
>
>    d. Ignoring the ramifications of the end-to-end principle,
>       which are often more subtle than people seem to think
>       they are. The bundle protocol's custody transfer
>       procedure is a good example of this failing.
>
>    e. The bundle protocol is intended for use in the most
>       difficult noisy disrupted networking conditions we know,
>       and it can't even sanity check its own headers against
>       errors. (But hey, it now has a security protocol that
>       _almost_ does that! But which is too complicated, and
>       would need to be redone.)
>       It's intended for the harshest environments we know,
>       but needs reliable synchronized clocks running at
>       steady temperatures!
>       It's intended for embedded systems, but the design
>       is huge and complex! (CFDP has the same problem;
>       there's a reason implementers went for a "CFDP lite,"
>       and Saratoga exists just because CFDP wasn't performing.
>       Would RFC5050bis be "bundling lite"?)
>       There are many 'that makes no sense' moments - normally
>       more immediately visible to outsiders not steeped in
>       the dogma, politics, and history of DTNRG and CCSDS.
>
>    f. The assumption that a full security suite is desirable
>       and necessary at all times. This has derailed DTNRG,
>       as emphasis was placed on security work above all
>       else, rather than working to the scenario. To be fair
>       to the security-focused chairs, the charter that
>       established DTNRG from the interplanetary internet
>       research group called out security heavily, and they
>       ran with that mandate. But the focus has decreased
>       work on non-security matters, which is to say,
>       everything else.
>
> RFC5050bis might address the latter three problems, but
> the first three are intrinsically unsolvable; any solution
> will be unsatisfactory. Perhaps not as unsatisfactory as
> RFC5050, but unsatisfactory nonetheless.
>
> The real philosophical problem here is the political dogma
> that, whatever the problem, the bundle protocol is The
> One True Solution.
>
>
> 4. The draft BOF charter is bundle-centric. Which is to say,
>    that it's not awfully relevant to internet standards.
>    Disclaimer of interest: we've worked on Saratoga and
>    HTTP-DTN, which have current internet-drafts, and are
>    squarely in the DTN problem space.
>    Whenever someone talks about multiple convergence
>    layers for the bundle protocol - there's more than for BEEP,
>    which just has TCP, but there aren't many - Saratoga may
>    be mentioned. But we've found that carrying bundles doesn't
>    benefit Saratoga - tested it in space, didn't see the
>    advantages. Saratoga does leverage a few Internet things -
>    UDP, UDP-Lite, multicast. It does a few scaling things that
>    nothing else I've seen does (described in our 2011 TSVAREA
>    presentation to IETF 88 in November.) And it's based on
>    a decade of operational use in the problem domain.
>    HTTP-DTN leverages the HTTP suite and MIME, and comes up
>    whenever wouldn't-it-be-nice-to-try-HTTP-for-DTN discussion
>    takes place.
>    (I suspect that all of Stephen Farrell's N4C work could
>    have been done over hop-by-hop HTTP a la HTTP-DTN, and
>    would have worked just as well if not better. After all,
>    it used TCP.)
>    These and other efforts exist in a gap between DTNRG, which
>    is aware of the problem space, but thinks the bundle
>    protocol is the solution despite mounting evidence to the
>    contrary, and TSVWG, where the few actual transport
>    experts live, without clout, or funding, or spare time.
>    Those efforts are interesting enough to have implementations
>    kicking around too.
>    And yet, the focus of this putative workgroup and BOF is
>    solely on bundling, and not on evaluating these or other
>    things that might exist in the problem space. There
>    must be other things out there that would be of interest
>    to such a DTN workgroup. What is proposed is not a DTN
>    workgroup. The charter is basically a bundle workgroup.
>    Can an interest in bundling and solely bundling (outside
>    CCSDS, which is driving the push to use the bundle protocol)
>    be justified for an IETF workgroup? I really don't think so.
>
> 5. The bundle protocol work was, I gather, well-funded
>    by a number of parties.
>    I can't see a follow-on effort being anywhere near
>    as well funded.
>
>    a. I have no idea how much money NASA and CCSDS have put
>       into this - first CFDP, then bundling, which now has
>       to provide a CFDP-like API to the users who were told
>       that CFDP was the future, and Licklider (LTP).
>       Dragging CCSDS into the modern age of networking
>       seems unlikely to ever happen, thanks to CCSDS having
>       little in the way of sane layering or separation of
>       functionality.
>       I do have the luxury of not needing to work on CCSDS.
>       But if you want to work on CCSDS protocols, CCSDS is
>       the place to go. The IETF is not that place.
>
>    b. DARPA poured money into DTN work - at least twenty
>       million dollars, from the press releases I've seen.
>       I have no idea what DARPA got out of it in the
>       years they were involved; haven't seen the reports.
>
> My point is, all that money and effort and manpower and
> over a decade of work and prior experience with CFDP and two
> IRTF RGs, we have... RFC5050.
> There is nowhere near as much money or effort or manpower
> for doing a replacement.
> Ergo, it might be suggested that the replacement is unlikely
> to be as good as RFC5050, or as good as CFDP; at best,
> the usual suspects will have less time and fewer resources
> to repeat their original mistakes.
>
> And transport expertise from TSVWG would be needed.
> TSVWG is unfashionable, low-visibility, and has even
> previously had trouble finding ADs with relevant expertise.
> And TSVWG has a full plate with work on its existing
> protocols; there is not a lot of expertise, and what there
> is is spread thin.
> So an RFC505bis effort is unlikely to get the expert
> technical input that it sorely needs, even if an IETF
> workgroup is set up. (CCSDS doesn't have that transport
> focus.)
>
> If, on the other hand, you believe good protocol design
> can be done more cheaply and leverage actual Internet
> standards to get Internet functionality working in
> difficult networks where the full TCP/IP suite has
> trouble, your options include Saratoga and HTTP-DTN!
> http://saratoga.sourceforge.net/
> http://sat-net.com/L.Wood/dtn/http-dtn.html
> They'll truly extend the Internet to difficult
> environments. The bundle protocol won't.
>
> So, to conclude, there is no justification for going
> standards track. There is little justification for an
> IETF workgroup. There is more logic in rechartering and
> repurposing the IRTF DTNRG, but the work may as well
> be left to CCSDS entirely.
>
> RFC5050bis: half-assed, half-baked, reheated.
> But hey, ask me what I _really_ think.
>
> Lloyd Wood
> http://sat-net.com/L.Wood/dtn/
>
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn