Subject: [dtn] Aside: the kind of charter I'd like

From: Stephen Farrell <[email-masked]>
Date: Mon, 08 Sep 2014 11:29:08 +0100

So as I said before a few times, I do think I'm in the rough
on this, but the text below is where I'd like to have started
in a charter discussion. At the BoF however, I thought that
I was less in the rough than I expected, so I'll send this one
mail and see if it gets a bunch of support. I don't expect it
will, in which case I'll stop asking:-)

In other words, if you don't like this, and prefer Marc's you
don't need to say so unless other folks first do say they like
this. That is, silence here == forget about it:-)

And btw, this is not something suited for the DTNRG. This
is pure protocol engineering and involves no research so
researchers will quite properly not spend time on this, just
as they have not spent time on any 5050bis effort.

Cheers,
S.

The DTN architecture (RFC 4838) and protocols developed according
to that architecture (RFCs 5050, 5326) have been successfully used
in small scale trials and by the space community. As a result a
number of relatively minor functional deficiencies have been
discovered (e.g. the need for relative timing for bundle expiry). A
number of those are documented in <draft-foo>.

However, despite this small-scale success, the bundle protocol (RFC
5050) has not seen widespread deployment and is not considered a
tool of choice for developers dealing with delay and disruption on
the Internet today.  Among the reasons for this are that it is not
easy to build a DTN from commonly used developer tools and still
interoperate with an RFC 5050 DTN. The fact that an RFC 5050 DTN
can't easily make use of deployed infrastructure (be that for
messaging or the web) also imposes a very high hurdle for
deployments.

The goal of the DTNWG is to develop a protocol that 1) adheres to
the DTN architecture, 2) that allows for relatively simple
gatewaying to an RFC5050 DTN, but that 3) is far more likely to be
deployed by developers using commonly available tooling and
existing deployed infrastructure.

The DTNWG has one deliverable (possibly in multiple RFCs) which is
a replacement protocol for RFC5050 meeting the above high level
requirements and the DTN functional requirements aleady met by
RFC5050 and co.

---

From: John Dowdell <[email-masked]>
Date: Mon, 08 Sep 2014 12:15:32 +0100

On 08/09/14 11:29, Stephen Farrell wrote:
> <snip>
Stephen, I would not lose heart over this. You're trying to solve the 
problem, not provide an easy way out for developers. SIP is a case in 
point; years ahead of its time, many large businesses now have an IP 
phone on every desk (even if the phone does not speak SIP), because of 
economic benefits in cabling and management. Mobile phone web browsing 
is another, but a different viewpoint; fine in principle, but because of 
heavily congested 3G infrastructure, it really doesn't work in practice. 
Go to any large exhibition or be a passenger on a main highway at rush 
hour and try to browse on your smartphone. I fear 4G will be like 
building more lanes on a motorway, bringing temporary relief but not 
actually fixing the problem. DTN should be the future for any traffic 
which is likely to be delayed because of poor quality infrastructure, 
but the commercial imperative is not there yet.

John

---

From: <[email-masked]>
Date: Mon, 8 Sep 2014 11:30:38 +0000

I prefer Stephen's proposed charter as more realistic and useful. I'd quibble over 'minor' though.

I think networking research needs a strong practical element to ground it: a lot of research work can and should be ignored simply because it is is not informed by wider practical experience.

(Stephen: congratulations on writing something not mentioning security.)

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________________
From: dtn <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
Sent: Monday, 8 September 2014 8:29:08 PM
To: [email-masked]
Subject: [dtn] Aside: the kind of charter I'd like

Cheers,
S.

_______________________________________________
dtn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtn

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Mon, 8 Sep 2014 12:47:19 +0000

I prefer to go this way.  This would easy critical items such as
discovery.  I thing it we may also be able to leverage Information Centric
Networking - perhaps even their ideas on securing named data.  This also
would put DTN in line with IETF if you are running DTN over IP.

On the other hand, if you are running IP over DTN over AOS (Advanced
Orbiting Systems), then you are really very space-spaecific and probably
should be handled by CCSDS (Consultative Committee for Space Data
Systems), not IETF.  I believe NASA is already headed down this road.

IMHO, the current RFC5050 implementations will be restricted to very small
custom deployments such as Space.

I would think Boeing would be more interested in large scale deployments,
but I really cannot tell.

-- Will

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Mon, 8 Sep 2014 16:48:48 +0000

John, thanks for this perspective.  DTN has been a long slog, but sometimes a long slog is the right way forward.

And Stephen, thanks for posting your preferred charter text, which does make your motivation a bit clearer, at least to me.  I appreciate your desire to keep the discussion on this topic positive.  At the same time, though, I don't think you can quite say "Here's my idea.  If you agree, please speak up, but if you don't then please don't say anything.  Then later on we'll tot up the comments and see if the community supports this idea."  The result wouldn't be quite accurate, would it?

If I read your proposed charter right, the essence of the initiative that you (and Lloyd, Will, and Wes, I guess) would advocate is that (a) development and deployment of RFC5050-based networks is difficult to do using commonly available tools and infrastructure; (b) this difficulty in development and deployment is the reason RFC5050-based networking has not been widely adopted; (c) the way to infuse delay-tolerant networking concepts more broadly in industry is to discard RFC5050 and start over again.  Correct?

Speaking just for myself, I have seen no evidence that any of these three propositions are true.  The existence of a half-dozen or more interoperable code bases argues that implementation of RFC5050 isn't an especially insuperable obstacle.  Deploying new networks is tedious, sure, but that's because deployment tools are needed.  When and if there's industry demand for easier deployment, somebody will finally get paid to develop those tools.  But ease of deployment was -- and is -- never going to create demand for delay-tolerant networking.  Only (eventually) mounting user frustration with existing alternatives is going to create that demand, and with a couple of minor tweaks the Bundle Protocol will be amply able to satisfy it.

However, I would be very glad to see what would come out of such an alternative initiative, and in fact I have been waiting for that since 2009 or thereabouts.  This idea has been around for a long time; where are the interoperable implementations?  Where are the pilot deployments?  Where are the carefully documented demonstrations of the superiority of this approach?  Why hasn't anybody built it?  Surely the existence of one robust research program doesn't preclude the establishment of another.

That is, I think this concept is being proffered to the wrong customers.  We who are working on BP-based technology are not in a position to fund the development of an alternative.  The business entities that are paying us -- NASA, Boeing, originally DARPA -- are the people who need to be convinced.

At this time, though, they seem to be content with the direction established by the 5050 family of RFCs.  They seem to see the prospect of near-term operational advantage in the use of those protocols, which is why they are underwriting the formation of an IETF working group to standardize them.  That, finally, is the reason I think the charter concept you are proposing is somewhat in the rough.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of John Dowdell
Sent: Monday, September 08, 2014 4:16 AM
To: [email-masked]
Subject: Re: [dtn] Aside: the kind of charter I'd like

On 08/09/14 11:29, Stephen Farrell wrote:
> 5050) has not seen widespread deployment and is not considered a tool 
> of choice for developers dealing with delay and disruption on the 
> Internet today.  Among the reasons for this are that it is not easy to 
> build a DTN from commonly used developer tools and still interoperate 
> with an RFC 5050 DTN. The fact that an RFC 5050 DTN can't easily make 
> use of deployed infrastructure (be that for messaging or the web) also 
> imposes a very high hurdle for deployments.
>
>
Stephen, I would not lose heart over this. You're trying to solve the problem, not provide an easy way out for developers. SIP is a case in point; years ahead of its time, many large businesses now have an IP phone on every desk (even if the phone does not speak SIP), because of economic benefits in cabling and management. Mobile phone web browsing is another, but a different viewpoint; fine in principle, but because of heavily congested 3G infrastructure, it really doesn't work in practice. 
Go to any large exhibition or be a passenger on a main highway at rush hour and try to browse on your smartphone. I fear 4G will be like building more lanes on a motorway, bringing temporary relief but not actually fixing the problem. DTN should be the future for any traffic which is likely to be delayed because of poor quality infrastructure, but the commercial imperative is not there yet.

John

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Sep 2014 18:12:42 +0000

Hi John,

> but the commercial imperative is not there yet.

Yes, I would agree and I think we can also historically point
out how the Internet protocols panned out as the bedrock for
the modern day Internet instead of alternatives such as OSI
networking. Perfection is not necessary - rough consensus
and running code are.

Thanks - Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Sep 2014 18:17:12 +0000

> but I really cannot tell.

The Internet approaches scaling through the concatenation of a
"network of networks". DTN scaling will be realized through the
concatenation of a "DTN of DTNs". We can assemble a DTN with
the expectation that it may someday be joined together with
other DTNs to form a larger DTN. But for now, my use cases are
satisfied by focusing on what goes on inside of a single DTN.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Sep 2014 18:18:26 +0000

Speaking for myself but also as a Boeing employee, we prefer a solution
based on the already-demonstrated technologies that are available in
multiple interoperable implementations rather than (re)invent something
from scratch.

Thanks - Fred

> From: dtn [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (312G)
> Sent: Monday, September 08, 2014 9:49 AM
> To: John Dowdell; [email-masked]
> And Stephen, thanks for posting your preferred charter text, which does make your motivation a bit
> clearer, at least to me.  I appreciate your desire to keep the discussion on this topic positive.  At
> the same time, though, I don't think you can quite say "Here's my idea.  If you agree, please speak
> up, but if you don't then please don't say anything.  Then later on we'll tot up the comments and see
> if the community supports this idea."  The result wouldn't be quite accurate, would it?
> 
> If I read your proposed charter right, the essence of the initiative that you (and Lloyd, Will, and
> Wes, I guess) would advocate is that (a) development and deployment of RFC5050-based networks is
> difficult to do using commonly available tools and infrastructure; (b) this difficulty in development
> and deployment is the reason RFC5050-based networking has not been widely adopted; (c) the way to
> infuse delay-tolerant networking concepts more broadly in industry is to discard RFC5050 and start
> over again.  Correct?
> 
> Speaking just for myself, I have seen no evidence that any of these three propositions are true.  The
> existence of a half-dozen or more interoperable code bases argues that implementation of RFC5050 isn't
> an especially insuperable obstacle.  Deploying new networks is tedious, sure, but that's because
> deployment tools are needed.  When and if there's industry demand for easier deployment, somebody will
> finally get paid to develop those tools.  But ease of deployment was -- and is -- never going to
> create demand for delay-tolerant networking.  Only (eventually) mounting user frustration with
> existing alternatives is going to create that demand, and with a couple of minor tweaks the Bundle
> Protocol will be amply able to satisfy it.
> 
> However, I would be very glad to see what would come out of such an alternative initiative, and in
> fact I have been waiting for that since 2009 or thereabouts.  This idea has been around for a long
> time; where are the interoperable implementations?  Where are the pilot deployments?  Where are the
> carefully documented demonstrations of the superiority of this approach?  Why hasn't anybody built it?
> Surely the existence of one robust research program doesn't preclude the establishment of another.
> 
> That is, I think this concept is being proffered to the wrong customers.  We who are working on BP-
> based technology are not in a position to fund the development of an alternative.  The business
> entities that are paying us -- NASA, Boeing, originally DARPA -- are the people who need to be
> convinced.
> 
> At this time, though, they seem to be content with the direction established by the 5050 family of
> RFCs.  They seem to see the prospect of near-term operational advantage in the use of those protocols,
> which is why they are underwriting the formation of an IETF working group to standardize them.  That,
> finally, is the reason I think the charter concept you are proposing is somewhat in the rough.
> 
> Scott
> 
> Stephen, I would not lose heart over this. You're trying to solve the problem, not provide an easy way
> out for developers. SIP is a case in point; years ahead of its time, many large businesses now have an
> IP phone on every desk (even if the phone does not speak SIP), because of economic benefits in cabling
> and management. Mobile phone web browsing is another, but a different viewpoint; fine in principle,
> but because of heavily congested 3G infrastructure, it really doesn't work in practice.
> Go to any large exhibition or be a passenger on a main highway at rush hour and try to browse on your
> smartphone. I fear 4G will be like building more lanes on a motorway, bringing temporary relief but
> not actually fixing the problem. DTN should be the future for any traffic which is likely to be
> delayed because of poor quality infrastructure, but the commercial imperative is not there yet.
> 
> John
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 08 Sep 2014 20:03:11 +0100

Hi Scott,

On 08/09/14 17:48, Burleigh, Scott C (312G) wrote:
> And Stephen, thanks for posting your preferred charter text, which
> does make your motivation a bit clearer, at least to me.  I
> appreciate your desire to keep the discussion on this topic positive.
> At the same time, though, I don't think you can quite say "Here's my
> idea.  If you agree, please speak up, but if you don't then please
> don't say anything.  Then later on we'll tot up the comments and see

That wasn't the intent. I just meant to not disturb the list
if nobody else cared enough to even respond. Now there's
discussion though, let's chat... (And I think I'm bending over
to be fair, constantly admitting I'm probably in the rough:-)

> If I read your proposed charter right, the essence of the initiative
> that you (and Lloyd, Will, and Wes, I guess) would advocate is that
> (a) development and deployment of RFC5050-based networks is difficult
> to do using commonly available tools and infrastructure; 

Complying with 5050 is very difficult with widely available
tools. There are no SDNV or other highly useful bits of 5050
that are available, except in the specific 5050 implementations.
No other tools have any 5050 features at all that I know of. One
has to write from scratch in all cases. (With the exception of
the CMS stuff used in the BSP, which is its own can of worms;-)

And interop with a 5050 DTN is impossible using deployed
infrastructure except as an effectively infeasible overlay.
CDNs, web proxies, MTAs for mail and IM networks all exist and
are unusable for 5050 in any interoperable manner. While we
do have wireshark filters that's about the limit of the
5050 support one finds in the wild I think. There are a
number of implementations yes, but they are maintained in
"heartbleed" mode, by one or two people only who have other
day jobs. We saw how that panned out with openssl;-)

And there is no stackoverflow like infrastructure for 5050
developers. Compared to a decade ago, I think that's highly
significant.

> (b) this
> difficulty in development and deployment is the reason RFC5050-based
> networking has not been widely adopted; 

No. I did not say "the reason" I said "a reason." I do think
however it is the most significant reason being ignored by the
minimal-approach proposed charter. (That is, of all the things
ignored by the minimal-approach, this is the most significant.)

> (c) the way to infuse
> delay-tolerant networking concepts more broadly in industry is to
> discard RFC5050 and start over again.  Correct?

No. Your (c) is overstated in a significantly pejorative manner.

We (the DTN community and here in TCD) have years of experience
with 5050. Using that experience in order to inform a redesign
of an essentially decade-old protocol that has not been widely
deployed is entirely reasonable. And especially given the way
that e.g. the web has developed in that time (e.g. async calls,
node.js being all over the place, http/2.0 being binary with
no head of line blocking...) But that sounds utterly different
from "discard... and start over" doesn't it?

Anyway, I don't believe we need to disparage alternatives here.

> Speaking just for myself, I have seen no evidence that any of these
> three propositions are true.  

I have. In Sweden the 2 things people really wanted were banking
and social networking. Neither can be delivered in practice with
5050. The GAIA RG-in-formation is not afaik looking at all at
5050 despite the clear match in requirements and even overlap in
personnel. For any example I've examined that requires user
interface coding (e.g. remote backup for satellite broadband
users), the benefit of 5050-based DTN is insufficient - its cheaper
to handle the DTN requirements in the application if you have to
write/test UI code. For many other applications I've looked at,
deploying a new set of routers is impossible for administrative
reasons. On the Internet, we describe types using MIME (e.g.
application/jpeg) and 5050 would require all that to be re-developed
or else pointless layering. We have seen about 5 different ways
to tunnel HTTP in bundles, none of which interop and that's a
fail. We don't even afaik have two implementations of SMTP/5050
that'd interop. Etc etc. There is, outside the space environment,
lots and lots of readily available evidence I think.

Frankly, asserting that 5050 is easy to develop and deploy would
be utterly indefensible really, as I hope you agree.

> The existence of a half-dozen or more
> interoperable code bases argues that implementation of RFC5050 isn't
> an especially insuperable obstacle.  

"isn't... especially insuperable" is not a very attractive target
to be honest.

> Deploying new networks is
> tedious, sure, but that's because deployment tools are needed.  When
> and if there's industry demand for easier deployment, somebody will
> finally get paid to develop those tools.  But ease of deployment was
> -- and is -- never going to create demand for delay-tolerant
> networking.  Only (eventually) mounting user frustration with
> existing alternatives is going to create that demand, and with a
> couple of minor tweaks the Bundle Protocol will be amply able to
> satisfy it.

"Amply"? TBBA I think, no? And I think ignoring deployability,
which is what I read in the above, flies in the face of a major
lesson the Internet community have learned over the last couple
of decades.

> However, I would be very glad to see what would come out of such an
> alternative initiative, and in fact I have been waiting for that
> since 2009 or thereabouts.  This idea has been around for a long
> time; where are the interoperable implementations?  Where are the
> pilot deployments?  Where are the carefully documented demonstrations
> of the superiority of this approach?  Why hasn't anybody built it?

What I'm proposing is not a research programme. Its engineering,
in the IETF sense. I think we both know that there are not
sufficient volunteer cycles likely available for two such
engineering activities to run in parallel.

> That is, I think this concept is being proffered to the wrong
> customers.  We who are working on BP-based technology are not in a
> position to fund the development of an alternative.  

That begs the question by pre-supposing "we" are working only
on 5050 based technology. (In the same sense that someone who
argues against http/2.0 because it is not http/1.1 would be
begging the question as to whether or not httpbis ought work
on http/2.0. And that did happen;-)

> The business
> entities that are paying us -- NASA, Boeing, originally DARPA -- are
> the people who need to be convinced.

Sure. That's partly why I'm asking. If I were a funder in any
of those agencies I'd be more interested in a technology that
could become ubiquitous rather than in further development of
what is likely to always be a niche protocol. But what do I
know, I just spend those cheques, I don't write 'em:-)

> At this time, though, they seem to be content with the direction
> established by the 5050 family of RFCs.  They seem to see the
> prospect of near-term operational advantage in the use of those
> protocols, which is why they are underwriting the formation of an
> IETF working group to standardize them.  

Hmm. Put another way: those espousing the minimal charter do
not need to see widespread availability of DTN features and so
are therefore ok with a 5050 based approach. That doesn't mean
that's a wise course of action though but I agree that "we do
not need that" is a good argument against my preferred approach
if the set of folks saying that are enough to get the work done.

> That, finally, is the reason
> I think the charter concept you are proposing is somewhat in the
> rough.

I also (as I've repeatedly said) believe I'm probably in the
rough here. If you and others want to do work on the minimal
approach, that's just fine. But not very interesting for me
at least. I continue to think though that the minimal approach
is short-sighted and represents a missed opportunity. (I may
well be wrong of course, that happens all the time and I'm well
used to it:-)

Cheers,
S.

> 
> Scott
> 
> -----Original Message----- From: dtn [mailto:[email-masked]] On
> Behalf Of John Dowdell Sent: Monday, September 08, 2014 4:16 AM To:
> [email-masked] Subject: Re: [dtn] Aside: the kind of charter I'd like
> 
>> However, despite this small-scale success, the bundle protocol
>> (RFC 5050) has not seen widespread deployment and is not considered
>> a tool of choice for developers dealing with delay and disruption
>> on the Internet today.  Among the reasons for this are that it is
>> not easy to build a DTN from commonly used developer tools and
>> still interoperate with an RFC 5050 DTN. The fact that an RFC 5050
>> DTN can't easily make use of deployed infrastructure (be that for
> phone on every desk (even if the phone does not speak SIP), because
> of economic benefits in cabling and management. Mobile phone web
> browsing is another, but a different viewpoint; fine in principle,
> but because of heavily congested 3G infrastructure, it really doesn't
> work in practice. Go to any large exhibition or be a passenger on a
> main highway at rush hour and try to browse on your smartphone. I
> fear 4G will be like building more lanes on a motorway, bringing
> temporary relief but not actually fixing the problem. DTN should be
> the future for any traffic which is likely to be delayed because of
> poor quality infrastructure, but the commercial imperative is not
> there yet.
> 
> John
> 
> _______________________________________________ dtn mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dtn
> 
> _______________________________________________ dtn mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dtn
>

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Mon, 8 Sep 2014 21:15:48 +0000

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Monday, September 08, 2014 12:03 PM
To: Burleigh, Scott C (312G); John Dowdell; [email-masked]
Subject: Re: [dtn] Aside: the kind of charter I'd like

> to do using commonly available tools and infrastructure;

Complying with 5050 is very difficult with widely available tools. There are no SDNV or other highly useful bits of 5050 that are available, except in the specific 5050 implementations.
No other tools have any 5050 features at all that I know of. One has to write from scratch in all cases. (With the exception of the CMS stuff used in the BSP, which is its own can of worms;-)

[Scott]  Hmmm.  I didn't find it was very difficult, mostly.  The SDNV encoder and decoder in ION add up to 85 source lines, of which 32 are comments and white space.  Dealing with the dictionary is a nightmare, I'm with you there.

And interop with a 5050 DTN is impossible using deployed infrastructure except as an effectively infeasible overlay.
CDNs, web proxies, MTAs for mail and IM networks all exist and are unusable for 5050 in any interoperable manner.

[Scott]  Okay, you're not talking about the difficulty of running DTN over low-level infrastructure (e.g., sockets), which we do all the time -- you're talking about the difficulty of running high-level infrastructure (CDNs, IM, etc.) over DTN, right?  That's a good point, but it seems to me that it argues not for ditching the Bundle Protocol but for devising a BP API that makes it easy for CDNs, IM, etc. to invoke BP functionality.  (Which would be the same sort of API that a starting-over DTN would offer, for easy integration with the deployed infrastructure, yes?)

While we do have wireshark filters that's about the limit of the
5050 support one finds in the wild I think. There are a number of implementations yes, but they are maintained in "heartbleed" mode, by one or two people only who have other day jobs. We saw how that panned out with openssl;-)

[Scott]  Actually, for several of us the maintenance of these implementations is our day job.  But I agree, the BP software provider community is not Microsoft-sized.

And there is no stackoverflow like infrastructure for 5050 developers. Compared to a decade ago, I think that's highly significant.

> networking has not been widely adopted;

No. I did not say "the reason" I said "a reason." I do think however it is the most significant reason being ignored by the minimal-approach proposed charter. (That is, of all the things ignored by the minimal-approach, this is the most significant.)

We (the DTN community and here in TCD) have years of experience with 5050. Using that experience in order to inform a redesign of an essentially decade-old protocol that has not been widely deployed is entirely reasonable. And especially given the way that e.g. the web has developed in that time (e.g. async calls, node.js being all over the place, http/2.0 being binary with no head of line blocking...) But that sounds utterly different from "discard... and start over" doesn't it?

[Scott]  Yes.  It also sounds utterly different from what you wrote in the third paragraph of your proposed charter.

[Scott]  I didn't think I was being disparaging; I thought I was simply transcribing what you wrote.  But okay, let's be very careful not to disparage alternatives.  Either of them.

> three propositions are true.

I have. In Sweden the 2 things people really wanted were banking and social networking. Neither can be delivered in practice with 5050.

[Scott]  Why not?  I can think of several ways of doing both.

The GAIA RG-in-formation is not afaik looking at all at 5050 despite the clear match in requirements and even overlap in personnel.

[Scott]  RFC 5050 is a pretty good match for a very small subset of the GAIA requirements.  GAIA have got lots more interesting issues to resolve. 

For any example I've examined that requires user interface coding (e.g. remote backup for satellite broadband users), the benefit of 5050-based DTN is insufficient - its cheaper to handle the DTN requirements in the application if you have to write/test UI code.

[Scott]  I certainly agree that 5050 offers no advantage in developing GUIs.  And sure, it often seems cheaper to roll your own code than to integrate with an existing implementation that does a lot of things you don't need.

For many other applications I've looked at, deploying a new set of routers is impossible for administrative reasons.

[Scott]  Why new routers?  If you don't need disruption-tolerance in your routers, you probably shouldn't be using DTN routers.

On the Internet, we describe types using MIME (e.g. application/jpeg) and 5050 would require all that to be re-developed or else pointless layering.

[Scott]  I don't think so.  Why not put the MIME header in an extension block?

We have seen about 5 different ways to tunnel HTTP in bundles, none of which interop and that's a fail.

[Scott]  No, it's research.  If we were unable to converge on one interoperable method in the working group, that would be a failure.

We don't even afaik have two implementations of SMTP/5050 that'd interop.

[Scott]  You're probably right, but I suspect that would be solved pretty quickly after somebody decided they actually needed email over BP (as opposed to just being interested in it).

Etc etc. There is, outside the space environment, lots and lots of readily available evidence I think.

Frankly, asserting that 5050 is easy to develop and deploy would be utterly indefensible really, as I hope you agree.

[Scott]  I certainly agree that it could be made easier.  I disagree that this difficulty is a significant obstacle to adoption of the technology.

> networking.  Only (eventually) mounting user frustration with existing 
> alternatives is going to create that demand, and with a couple of 
> minor tweaks the Bundle Protocol will be amply able to satisfy it.

"Amply"? TBBA I think, no? And I think ignoring deployability, which is what I read in the above, flies in the face of a major lesson the Internet community have learned over the last couple of decades.

[Scott]  I have no idea what TBBA means, but reading the above as "ignoring deployability" is a stretch.  I said DTN will become easier to deploy when industry needs to deploy a lot of it.

> alternative initiative, and in fact I have been waiting for that since 
> 2009 or thereabouts.  This idea has been around for a long time; where 
> are the interoperable implementations?  Where are the pilot 
> deployments?  Where are the carefully documented demonstrations of the 
> superiority of this approach?  Why hasn't anybody built it?

What I'm proposing is not a research programme. Its engineering, in the IETF sense. I think we both know that there are not sufficient volunteer cycles likely available for two such engineering activities to run in parallel.

[Scott]  The Bundle Protocol work that we're talking about here doesn't rely much on volunteer cycles, so I would expect there are plenty of volunteer cycles left over for an additional activity.

> position to fund the development of an alternative.

That begs the question by pre-supposing "we" are working only on 5050 based technology. (In the same sense that someone who argues against http/2.0 because it is not http/1.1 would be begging the question as to whether or not httpbis ought work on http/2.0. And that did happen;-)

[Scott]  Not at all.  To "beg the question" is to take the conclusion of one's argument as an assumption underlying the argument.  I'm simply encouraging you to take your initiative to somebody who is willing and able to bring it to reality.

> the people who need to be convinced.

Sure. That's partly why I'm asking. If I were a funder in any of those agencies I'd be more interested in a technology that could become ubiquitous rather than in further development of what is likely to always be a niche protocol. But what do I know, I just spend those cheques, I don't write 'em:-)

[Scott]  Actually you might not be especially interested in a technology that could become ubiquitous.  You might be more interested in a technology that solved the problems you needed to solve.  (But of course I don't know either; I've got no budget authority at all, thank goodness.)

> established by the 5050 family of RFCs.  They seem to see the prospect 
> of near-term operational advantage in the use of those protocols, 
> which is why they are underwriting the formation of an IETF working 
> group to standardize them.

Hmm. Put another way: those espousing the minimal charter do not need to see widespread availability of DTN features and so are therefore ok with a 5050 based approach. That doesn't mean that's a wise course of action though but I agree that "we do not need that" is a good argument against my preferred approach if the set of folks saying that are enough to get the work done.

[Scott]  Well, what you have "put another way" is perhaps a good match for what I "overstated in a significantly pejorative manner" above, so maybe we're even.

> I think the charter concept you are proposing is somewhat in the 

I also (as I've repeatedly said) believe I'm probably in the rough here. If you and others want to do work on the minimal approach, that's just fine. But not very interesting for me at least. I continue to think though that the minimal approach is short-sighted and represents a missed opportunity. (I may well be wrong of course, that happens all the time and I'm well used to it:-)

Cheers,
S.

>> Internet today.  Among the reasons for this are that it is not easy 
>> to build a DTN from commonly used developer tools and still 
> is another, but a different viewpoint; fine in principle, but because 
> of heavily congested 3G infrastructure, it really doesn't work in 
> practice. Go to any large exhibition or be a passenger on a main 
> highway at rush hour and try to browse on your smartphone. I fear 4G 
> will be like building more lanes on a motorway, bringing temporary 
> relief but not actually fixing the problem. DTN should be the future 
> for any traffic which is likely to be delayed because of poor quality 
> infrastructure, but the commercial imperative is not there yet.
> 
> John
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 08 Sep 2014 23:14:36 +0100

Hiya,

I figure we could debate this endlessly without convincing
one another, so.... probably better to not bother too much.
But sure a bit more won't kill us... :-)

On 08/09/14 22:15, Burleigh, Scott C (312G) wrote:
> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Monday, September 08, 2014
> 12:03 PM To: Burleigh, Scott C (312G); John Dowdell; [email-masked] 
>> If I read your proposed charter right, the essence of the
>> initiative that you (and Lloyd, Will, and Wes, I guess) would
>> advocate is that (a) development and deployment of RFC5050-based
>> networks is difficult to do using commonly available tools and
>> infrastructure;
> 
> Complying with 5050 is very difficult with widely available tools.
> There are no SDNV or other highly useful bits of 5050 that are
> available, except in the specific 5050 implementations. No other
> tools have any 5050 features at all that I know of. One has to write
> from scratch in all cases. (With the exception of the CMS stuff used
> in the BSP, which is its own can of worms;-)
> 
> [Scott]  Hmmm.  I didn't find it was very difficult, mostly.  The
> SDNV encoder and decoder in ION add up to 85 source lines, of which
> 32 are comments and white space.  Dealing with the dictionary is a
> nightmare, I'm with you there.

Sure, the bits aren't that hard or different. My point is that
I can't pick up code that does a significant chunk of 'em easily.
For any web-like protocol, I can. And that's important I think.

> infrastructure except as an effectively infeasible overlay. CDNs, web
> proxies, MTAs for mail and IM networks all exist and are unusable for
> 5050 in any interoperable manner.
> 
> [Scott]  Okay, you're not talking about the difficulty of running DTN
> over low-level infrastructure (e.g., sockets), which we do all the
> time -- you're talking about the difficulty of running high-level
> infrastructure (CDNs, IM, etc.) over DTN, right?  

Yep.

> That's a good
> point, but it seems to me that it argues not for ditching the Bundle
> Protocol but for devising a BP API that makes it easy for CDNs, IM,
> etc. to invoke BP functionality.  (Which would be the same sort of
> API that a starting-over DTN would offer, for easy integration with
> the deployed infrastructure, yes?)

I think such an API could be done, but would be much easier and
gain acceptance much more readily the more it is like other
similar things that CDNs etc are already doing.

> While we do have wireshark filters that's about the limit of the 5050
> support one finds in the wild I think. There are a number of
> implementations yes, but they are maintained in "heartbleed" mode, by
> one or two people only who have other day jobs. We saw how that
> panned out with openssl;-)
> 
> [Scott]  Actually, for several of us the maintenance of these
> implementations is our day job.  But I agree, the BP software
> provider community is not Microsoft-sized.

I do recognise that in the space community you have more
resources for this than we do in academia. And presumably the
Boeing folks and similar could get more should there be a reason.

But, what I'm after is not something as small as msft, but
rather more like being part of a github sized community
which I suspect is a lot bigger.

>> (b) this difficulty in development and deployment is the reason
>> RFC5050-based networking has not been widely adopted;
> 
> No. I did not say "the reason" I said "a reason." I do think however
> it is the most significant reason being ignored by the
>> (c) the way to infuse delay-tolerant networking concepts more
>> broadly in industry is to discard RFC5050 and start over again.
>> Correct?
> 
> We (the DTN community and here in TCD) have years of experience with
> 5050. Using that experience in order to inform a redesign of an
> essentially decade-old protocol that has not been widely deployed is
> entirely reasonable. And especially given the way that e.g. the web
> has developed in that time (e.g. async calls, node.js being all over
> the place, http/2.0 being binary with no head of line blocking...)
> But that sounds utterly different from "discard... and start over"
> doesn't it?
> 
> [Scott]  Yes.  It also sounds utterly different from what you wrote
> in the third paragraph of your proposed charter.

Fair enough. I do mean the same thing though. I agree my text
would be more convincing were there even a sketch of how one
might do it, which I've not done. Lloyd's HTTP ideas are not a
million miles away from what I'd suggest though, but there
would be some significant differences (that I've not had time
to document, sorry again).

> [Scott]  I didn't think I was being disparaging; I thought I was
> simply transcribing what you wrote.  But okay, let's be very careful
> not to disparage alternatives.  Either of them.
> 
> I have. In Sweden the 2 things people really wanted were banking and
> social networking. Neither can be delivered in practice with 5050.
> 

Yes, it could be done. But it will not be done is my point.
I'll bet you a beer no bank will use any derivative of 5050
in the next 5 years for that.

I think that's down to the need to, in practice, have a new
special DTN application for each that has code on each end
and that needs new (DTN) routers in the middle.

If one could somehow re-use the running code on the
non-disrupted parts of paths, then we might have a chance.
Significant crypto issues exist there too mind you for
banking, but for social networking, OAuth could be good
enough. But that requires glue between the web/OAuth and
5050 to exist at the edge of good connectivity which yes
is possible, but very unlikely because its quite a lot
of work since 5050 is so so different from the web.

> The GAIA RG-in-formation is not afaik looking at all at 5050 despite
> the clear match in requirements and even overlap in personnel.
> 
> [Scott]  RFC 5050 is a pretty good match for a very small subset of
> the GAIA requirements.  GAIA have got lots more interesting issues to
> resolve.

I've not seen 5050 mentioned on that list but maybe I missed it.

> 
> For any example I've examined that requires user interface coding
> (e.g. remote backup for satellite broadband users), the benefit of
> 5050-based DTN is insufficient - its cheaper to handle the DTN
> requirements in the application if you have to write/test UI code.
> 
> [Scott]  I certainly agree that 5050 offers no advantage in
> developing GUIs.  And sure, it often seems cheaper to roll your own
> code than to integrate with an existing implementation that does a
> lot of things you don't need.

I think s/seems cheaper/is cheaper/ in the above is correct.

> For many other applications I've looked at, deploying a new set of
> routers is impossible for administrative reasons.
> 
> [Scott]  Why new routers?  If you don't need disruption-tolerance in
> your routers, you probably shouldn't be using DTN routers.

Sorry I meant DTN routers, not IP routers. The issue I've seen is
that if those are in practice application specific there's again
no need for a complex DTN protocol and if they are generic, then
they need to be located somewhere I don't control usually (e.g. in
a PEP or access network). In either case, they don't get deployed.

> 
> On the Internet, we describe types using MIME (e.g. application/jpeg)
> and 5050 would require all that to be re-developed or else pointless
> layering.
> 

That's the pointless layering I meant:-) That block needs a type.
And it'd not be done cleanly is my bet - such IANA registry
replication rarely is clean I think. (What I mean is we'd almost
inevitably end up with >1 way to mean application/jpeg or whatever.)

> [Scott]  No, it's research.  If we were unable to converge on one
> interoperable method in the working group, that would be a failure.

I don't believe http interop for the web is a requirement for
the minimal approach. And that's fine, unless you accept my
argument that the minimal approach is mis-directed. My point was
more that we're missing a good target by not trying to aim to
solve the problems of a disrupted web as a first class
target. (That we ended up with 5 non-interoperable ways shows
that it was not a 1st class target I think.)

> [Scott]  You're probably right, but I suspect that would be solved
> pretty quickly after somebody decided they actually needed email over
> BP (as opposed to just being interested in it).
> 
> Frankly, asserting that 5050 is easy to develop and deploy would be
> utterly indefensible really, as I hope you agree.
> 
> [Scott]  I certainly agree that it could be made easier.  I disagree
> that this difficulty is a significant obstacle to adoption of the
> technology.

Yes, that last I think is where we significantly disagree.

>> Deploying new networks is tedious, sure, but that's because
>> deployment tools are needed.  When and if there's industry demand
>> for easier deployment, somebody will finally get paid to develop
>> those tools.  But ease of deployment was -- and is -- never going
>> to create demand for delay-tolerant networking.  Only (eventually)
>> mounting user frustration with existing alternatives is going to
>> create that demand, and with a couple of minor tweaks the Bundle
> "Amply"? TBBA I think, no? And I think ignoring deployability, which
> is what I read in the above, flies in the face of a major lesson the
> Internet community have learned over the last couple of decades.
> 
> [Scott]  I have no idea what TBBA means, 

Sorry, "truth by blatant assertion" - I'm as guilty of it as
you probably:-)

> but reading the above as
> "ignoring deployability" is a stretch.  I said DTN will become easier
> to deploy when industry needs to deploy a lot of it.

That's a clear position.

I figure that DTN will never be really needed while there are easier
to deploy ways to handle the problems for most cases. Which is a
pity.

>> pilot deployments?  Where are the carefully documented
>> demonstrations of the superiority of this approach?  Why hasn't
>> anybody built it? Surely the existence of one robust research
>> program doesn't preclude the establishment of another.
> 
> What I'm proposing is not a research programme. Its engineering, in
> the IETF sense. I think we both know that there are not sufficient
> volunteer cycles likely available for two such engineering activities
> to run in parallel.
> 
> [Scott]  The Bundle Protocol work that we're talking about here
> doesn't rely much on volunteer cycles, so I would expect there are
> plenty of volunteer cycles left over for an additional activity.

By volunteer cycles I meant the IETF WG stuff, which is still
fairly described as such even though you or others may have
DTN networking as part of your day job.

> That begs the question by pre-supposing "we" are working only on 5050
> based technology. (In the same sense that someone who argues against
> http/2.0 because it is not http/1.1 would be begging the question as
> to whether or not httpbis ought work on http/2.0. And that did
> happen;-)
> 
> [Scott]  Not at all.  To "beg the question" is to take the conclusion
> of one's argument as an assumption underlying the argument.  

I do think that's what you did, by defining "we" as those
working on 5050. But not worth quibbling over.

> I'm
> simply encouraging you to take your initiative to somebody who is
> willing and able to bring it to reality.
> 
>> The business entities that are paying us -- NASA, Boeing,
>> originally DARPA -- are the people who need to be convinced.
> 
> Sure. That's partly why I'm asking. If I were a funder in any of
> those agencies I'd be more interested in a technology that could
> become ubiquitous rather than in further development of what is
> likely to always be a niche protocol. But what do I know, I just
> spend those cheques, I don't write 'em:-)
> 
> [Scott]  Actually you might not be especially interested in a
> technology that could become ubiquitous.  You might be more
> interested in a technology that solved the problems you needed to
> solve.  (But of course I don't know either; I've got no budget
> authority at all, thank goodness.)
> 
> Hmm. Put another way: those espousing the minimal charter do not need
> to see widespread availability of DTN features and so are therefore
> ok with a 5050 based approach. That doesn't mean that's a wise course
> of action though but I agree that "we do not need that" is a good
> argument against my preferred approach if the set of folks saying
> that are enough to get the work done.
> 
> [Scott]  Well, what you have "put another way" is perhaps a good
> match for what I "overstated in a significantly pejorative manner"
> above, so maybe we're even.

Apologies if that came over badly, I really do think its fine
that you or others just want to solve specific problems with
5050 and don't want to try make DTN features ubiquitous. Yours
is not a goal with which I agree, but its an entirely defensible
goal in IETF terms. (Albeit misdirected.)

Cheers,
S.

>> That, finally, is the reason I think the charter concept you are
>> proposing is somewhat in the rough.
> 
> I also (as I've repeatedly said) believe I'm probably in the rough
> here. If you and others want to do work on the minimal approach,
> that's just fine. But not very interesting for me at least. I
> continue to think though that the minimal approach is short-sighted
> and represents a missed opportunity. (I may well be wrong of course,
> that happens all the time and I'm well used to it:-)
> 
> Cheers, S.
> 
> 
>> 
>> Scott
>> 
>> -----Original Message----- From: dtn [mailto:[email-masked]]
>> On Behalf Of John Dowdell Sent: Monday, September 08, 2014 4:16 AM
>> To: [email-masked] Subject: Re: [dtn] Aside: the kind of charter I'd
>> like
>> 
>>> (RFC 5050) has not seen widespread deployment and is not
>>> considered a tool of choice for developers dealing with delay and
>>> disruption on the Internet today.  Among the reasons for this are
>>> that it is not easy to build a DTN from commonly used developer
>>> tools and still interoperate with an RFC 5050 DTN. The fact that
>>> an RFC 5050 DTN can't easily make use of deployed infrastructure
>>> (be that for messaging or the web) also imposes a very high
>>> hurdle for deployments.
>>> 
>>> 
>> Stephen, I would not lose heart over this. You're trying to solve
>> the problem, not provide an easy way out for developers. SIP is a
>> case in point; years ahead of its time, many large businesses now
>> have an IP phone on every desk (even if the phone does not speak
>> SIP), because of economic benefits in cabling and management.
>> Mobile phone web browsing is another, but a different viewpoint;
>> fine in principle, but because of heavily congested 3G
>> infrastructure, it really doesn't work in practice. Go to any large
>> exhibition or be a passenger on a main highway at rush hour and try
>> to browse on your smartphone. I fear 4G will be like building more
>> lanes on a motorway, bringing temporary relief but not actually
>> fixing the problem. DTN should be the future for any traffic which
>> is likely to be delayed because of poor quality infrastructure, but
>> the commercial imperative is not there yet.
>> 
>> John
>>

---

From: <[email-masked]>
Date: Mon, 8 Sep 2014 22:37:04 +0000

> on http/2.0. And that did happen;-)

Your meaning of "begs the question" is unclear. ("TBBA"?)

If you're referring to previous discussion at e.g.
http://www.ietf.org/mail-archive/web/dtn-interest/current/msg04842.html
it can be a little difficult to explain to someone unfamiliar with the web
that, yes, http/2.0 does indeed have a higher version
number, but that doesn't necessarily mean it's better, and
that jumping from the overcomplex binary crud of 5050 to the 
overcomplex binary crud of whatever http/2.0 is this week
is probably not the best starting point for figuring out
what textual dtn-specific http headers are useful and
needed to map to wanted capabilities and
functionality in an actual DTN.

Which is why we didn't take that as a starting point.

Lloyd Wood
http://sat-net.com/L.Wood/dtn/http-dtn.html
________________________________________
From: dtn <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
Sent: Tuesday, 9 September 2014 5:03 AM
To: Burleigh, Scott C (312G); John Dowdell; [email-masked]
Subject: Re: [dtn] Aside: the kind of charter I'd like

Hi Scott,

Cheers,
S.

---

From: <[email-masked]>
Date: Mon, 8 Sep 2014 22:45:19 +0000

> But ease of deployment was -- and is -- never going to

Ironically, "A Bundle of Problems" was written due to user frustration with the Bundle Protocol,
after testing it on the ground and in space.

I know it was originally intended for the interplanetary internet, but I'm unsure what planet you're on.

Minor tweaks to fix major problems? Good luck with that.

Lloyd Wood

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Sep 2014 23:00:32 +0000

Hi Lloyd,

> From: dtn [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, September 08, 2014 3:45 PM
> To: [email-masked]; [email-masked]; [email-masked]

"A Bundle of Problems" was a problem statement with some good guidance
on things that could be addressed in a second edition. A second edition
is exactly what the draft wg charter calls for.

> I know it was originally intended for the interplanetary internet, but I'm unsure what planet you're

Really?

> Minor tweaks to fix major problems? Good luck with that.

Writing a problem statement is a far cry from "can't be fixed no
matter what". You wrote a problem statement.

Thanks - Fred

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 8 Sep 2014 19:20:33 -0400

> to document, sorry again).

I came to the conclusion a while ago that the only thing that could work and being accepted is to transport http over dtn and have apps developed over http. Then, the developers have very little need to change their programming environment.  That is what we've done with our postellation implementation. It worked pretty well with pretty long delays with real Internet apps.

So I don't think we need a new api. I think http over bp is just what we need in this regard. And I think others have also done similar work/implementations.

...

> inevitably end up with >1 way to mean application/jpeg or whatever.)

I have supported the idea to have some registry of application types. this is what we really need.

> that it was not a 1st class target I think.)

My take is that now is the time to standardize it.

And part of the problem is to get an app-type registry as I tried to propose soem time ago. 

...

> DTN networking as part of your day job.

I don't agree with your assessment that there is not enough volunteers. Where do you get that? We now have new people that came to the BOF that are from the industry. What else do we need?  Why are we presuming stuff like that?  I've seen other successful wg that relied just on a few active editors (or maybe that is the majority of the ietf wgs...) and worked just fine.

...

> goal in IETF terms. (Albeit misdirected.)

I again see really two threads:
a) one with "minimal changes to 5050", asked by industry, within the initial architecture and protocols.
b) another to start from scratch and learn from the 5050 experience, that might lead to a completely different set of protocols.

I think I proposed a charter for a), you are proposing for b). I was proposing that b) is folded into the research group. 

Regards, marc.

---

From: "Burleigh, Scott C (312G)" <[email-masked]>
Date: Mon, 8 Sep 2014 23:29:35 +0000

Thanks, Stephen; I think we've converged on the points on which we agree to disagree.  A constructive exchange of views.

Scott

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Monday, September 08, 2014 3:15 PM
To: Burleigh, Scott C (312G); [email-masked]
Subject: Re: [dtn] Aside: the kind of charter I'd like

Hiya,

I figure we could debate this endlessly without convincing one another, so.... probably better to not bother too much.
But sure a bit more won't kill us... :-)

On 08/09/14 22:15, Burleigh, Scott C (312G) wrote:
> available, except in the specific 5050 implementations. No other tools 
> have any 5050 features at all that I know of. One has to write from 
> scratch in all cases. (With the exception of the CMS stuff used in the 
> BSP, which is its own can of worms;-)
> 
> [Scott]  Hmmm.  I didn't find it was very difficult, mostly.  The SDNV 
> encoder and decoder in ION add up to 85 source lines, of which

Sure, the bits aren't that hard or different. My point is that I can't pick up code that does a significant chunk of 'em easily.
For any web-like protocol, I can. And that's important I think.

Yep.

> etc. to invoke BP functionality.  (Which would be the same sort of API 
> that a starting-over DTN would offer, for easy integration with the 
> deployed infrastructure, yes?)

I think such an API could be done, but would be much easier and gain acceptance much more readily the more it is like other similar things that CDNs etc are already doing.

> one or two people only who have other day jobs. We saw how that panned 
> out with openssl;-)
> 
> implementations is our day job.  But I agree, the BP software provider 
> community is not Microsoft-sized.

I do recognise that in the space community you have more resources for this than we do in academia. And presumably the Boeing folks and similar could get more should there be a reason.

But, what I'm after is not something as small as msft, but rather more like being part of a github sized community which I suspect is a lot bigger.

> And there is no stackoverflow like infrastructure for 5050 developers. 
> Compared to a decade ago, I think that's highly significant.
> 
> minimal-approach proposed charter. (That is, of all the things ignored 
> by the minimal-approach, this is the most significant.)
> 
>> (c) the way to infuse delay-tolerant networking concepts more broadly 
>> in industry is to discard RFC5050 and start over again.
>> Correct?
> 
> the place, http/2.0 being binary with no head of line blocking...) But 
> that sounds utterly different from "discard... and start over"
> doesn't it?
> 
> [Scott]  Yes.  It also sounds utterly different from what you wrote in 
> the third paragraph of your proposed charter.

Fair enough. I do mean the same thing though. I agree my text would be more convincing were there even a sketch of how one might do it, which I've not done. Lloyd's HTTP ideas are not a million miles away from what I'd suggest though, but there would be some significant differences (that I've not had time to document, sorry again).

Yes, it could be done. But it will not be done is my point.
I'll bet you a beer no bank will use any derivative of 5050 in the next 5 years for that.

I think that's down to the need to, in practice, have a new special DTN application for each that has code on each end and that needs new (DTN) routers in the middle.

If one could somehow re-use the running code on the non-disrupted parts of paths, then we might have a chance.
Significant crypto issues exist there too mind you for banking, but for social networking, OAuth could be good enough. But that requires glue between the web/OAuth and
5050 to exist at the edge of good connectivity which yes is possible, but very unlikely because its quite a lot of work since 5050 is so so different from the web.

> [Scott]  I certainly agree that 5050 offers no advantage in developing 
> GUIs.  And sure, it often seems cheaper to roll your own code than to 
> integrate with an existing implementation that does a lot of things 
> you don't need.

> your routers, you probably shouldn't be using DTN routers.

Sorry I meant DTN routers, not IP routers. The issue I've seen is that if those are in practice application specific there's again no need for a complex DTN protocol and if they are generic, then they need to be located somewhere I don't control usually (e.g. in a PEP or access network). In either case, they don't get deployed.

That's the pointless layering I meant:-) That block needs a type.
And it'd not be done cleanly is my bet - such IANA registry replication rarely is clean I think. (What I mean is we'd almost inevitably end up with >1 way to mean application/jpeg or whatever.)

> interoperable method in the working group, that would be a failure.

I don't believe http interop for the web is a requirement for the minimal approach. And that's fine, unless you accept my argument that the minimal approach is mis-directed. My point was more that we're missing a good target by not trying to aim to solve the problems of a disrupted web as a first class target. (That we ended up with 5 non-interoperable ways shows that it was not a 1st class target I think.)

>> deployment tools are needed.  When and if there's industry demand for 
>> easier deployment, somebody will finally get paid to develop those 
>> tools.  But ease of deployment was -- and is -- never going to create 
>> demand for delay-tolerant networking.  Only (eventually) mounting 
>> user frustration with existing alternatives is going to create that 
>> demand, and with a couple of minor tweaks the Bundle Protocol will be 
>> amply able to satisfy it.
> 

Sorry, "truth by blatant assertion" - I'm as guilty of it as you probably:-)

That's a clear position.

I figure that DTN will never be really needed while there are easier to deploy ways to handle the problems for most cases. Which is a pity.

> plenty of volunteer cycles left over for an additional activity.

By volunteer cycles I meant the IETF WG stuff, which is still fairly described as such even though you or others may have DTN networking as part of your day job.

> of one's argument as an assumption underlying the argument.

I do think that's what you did, by defining "we" as those working on 5050. But not worth quibbling over.

>> The business entities that are paying us -- NASA, Boeing, originally 
>> DARPA -- are the people who need to be convinced.
> 
> Sure. That's partly why I'm asking. If I were a funder in any of those 
> agencies I'd be more interested in a technology that could become 
> ubiquitous rather than in further development of what is likely to 
> always be a niche protocol. But what do I know, I just spend those 
> cheques, I don't write 'em:-)
> 
> technology that could become ubiquitous.  You might be more interested 
> in a technology that solved the problems you needed to solve.  (But of 
> course I don't know either; I've got no budget authority at all, thank 
> goodness.)
> 
> to see widespread availability of DTN features and so are therefore ok 
> with a 5050 based approach. That doesn't mean that's a wise course of 
> action though but I agree that "we do not need that" is a good 
> argument against my preferred approach if the set of folks saying that 
> are enough to get the work done.
> 
> [Scott]  Well, what you have "put another way" is perhaps a good match 
> for what I "overstated in a significantly pejorative manner"

Apologies if that came over badly, I really do think its fine that you or others just want to solve specific problems with
5050 and don't want to try make DTN features ubiquitous. Yours is not a goal with which I agree, but its an entirely defensible goal in IETF terms. (Albeit misdirected.)

Cheers,
S.

> that's just fine. But not very interesting for me at least. I continue 
> to think though that the minimal approach is short-sighted and 
> represents a missed opportunity. (I may well be wrong of course, that 
> happens all the time and I'm well used to it:-)
> 
> Cheers, S.
> 
> 
>> 
>> Scott
>> 
>> Behalf Of John Dowdell Sent: Monday, September 08, 2014 4:16 AM
>> of economic benefits in cabling and management.
>> Mobile phone web browsing is another, but a different viewpoint; fine 
>> in principle, but because of heavily congested 3G infrastructure, it 
>> really doesn't work in practice. Go to any large exhibition or be a 
>> passenger on a main highway at rush hour and try to browse on your 
>> smartphone. I fear 4G will be like building more lanes on a motorway, 
>> bringing temporary relief but not actually fixing the problem. DTN 
>> should be the future for any traffic which is likely to be delayed 
>> because of poor quality infrastructure, but the commercial imperative 
>> is not there yet.
>> 
>> John
>>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 09 Sep 2014 00:59:16 +0100

Hiya,

Responding just to a few bits, snipped.

On 09/09/14 00:20, Marc Blanchet wrote:
> I came to the conclusion a while ago that the only thing that could
> work and being accepted is to transport http over dtn and have apps
> developed over http. Then, the developers have very little need to
> change their programming environment.  That is what we've done with
> our postellation implementation. It worked pretty well with pretty
> long delays with real Internet apps.
> 
> So I don't think we need a new api. I think http over bp is just what
> we need in this regard. And I think others have also done similar
> work/implementations.

Yes, your postellation thing is a reasonable way to do http/5050.
And so was ours, and so was Jorg's;-)

But what I'm after is not that. I'd like us to make an http variant
that is delay-tolerant. None of the above approaches affect the
ease of implementation of the DTN stack itself.

> I don't agree with your assessment that there is not enough
> volunteers. Where do you get that? We now have new people that came
> to the BOF that are from the industry. What else do we need?  Why are
> we presuming stuff like that?  I've seen other successful wg that
> relied just on a few active editors (or maybe that is the majority of
> the ietf wgs...) and worked just fine.

My assertion is that there are not enough volunteer cycles to
pursue two approaches in parallel, regardless of WG/RG venue. I
assume that those who prefer the minimal approach will work on
just that.

> I again see really two threads: a) one with "minimal changes to
> 5050", asked by industry, within the initial architecture and
> protocols. b) another to start from scratch and learn from the 5050
> experience, that might lead to a completely different set of
> protocols.
> 
> I think I proposed a charter for a), you are proposing for b). I was
> proposing that b) is folded into the research group.

See above wrt folding into the DTNRG. I'll be happy to be
wrong, but I figure I'm not - IMO starting a WG means that
the RG goes into hibernation in practice. Recent list traffic
would seem to support that conclusion. And note - that is
not a problem in itself, both WGs and RGs only exist for
people to use as a useful venue. So my only contention is
that assuming that "WG does X and RG does Y,Z" is not
a sound assumption and hence is not a good argument for
the WG not addressing Y,Z.

Cheers,
S.

> 
> Regards, marc.
> 
>> 
>> Cheers, S.
>> 
>> 
>>>> That, finally, is the reason I think the charter concept you
>>>> are proposing is somewhat in the rough.
>>> 
>>> approach, that's just fine. But not very interesting for me at
>>> least. I continue to think though that the minimal approach is
>>> short-sighted and represents a missed opportunity. (I may well be
>>> wrong of course, that happens all the time and I'm well used to
>>> it:-)
>>> 
>>> Cheers, S.
>>> 
>>> 
>>>> 
>>>> Scott
>>>> 
>>>> -----Original Message----- From: dtn
>>>> [mailto:[email-masked]] On Behalf Of John Dowdell Sent:
>>>> Monday, September 08, 2014 4:16 AM To: [email-masked] Subject:
>>>> Re: [dtn] Aside: the kind of charter I'd like
>>>> 
>>>>> However, despite this small-scale success, the bundle
>>>>> protocol (RFC 5050) has not seen widespread deployment and is
>>>>> not considered a tool of choice for developers dealing with
>>>>> delay and disruption on the Internet today.  Among the
>>>>> reasons for this are that it is not easy to build a DTN from
>>>>> commonly used developer tools and still interoperate with an
>>>>> RFC 5050 DTN. The fact that an RFC 5050 DTN can't easily make
>>>>> use of deployed infrastructure (be that for messaging or the
>>>>> web) also imposes a very high hurdle for deployments.
>>>>> 
>>>>> 
>>>> Stephen, I would not lose heart over this. You're trying to
>>>> solve the problem, not provide an easy way out for developers.
>>>> SIP is a case in point; years ahead of its time, many large
>>>> businesses now have an IP phone on every desk (even if the
>>>> phone does not speak SIP), because of economic benefits in
>>>> cabling and management. Mobile phone web browsing is another,
>>>> but a different viewpoint; fine in principle, but because of
>>>> heavily congested 3G infrastructure, it really doesn't work in
>>>> practice. Go to any large exhibition or be a passenger on a
>>>> main highway at rush hour and try to browse on your smartphone.
>>>> I fear 4G will be like building more lanes on a motorway,
>>>> bringing temporary relief but not actually fixing the problem.
>>>> DTN should be the future for any traffic which is likely to be
>>>> _______________________________________________ dtn mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/dtn
>>>> 
>>>> _______________________________________________ dtn mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/dtn
>>>>

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 9 Sep 2014 10:08:06 +0000

Hi All,

I'll top post, as I have been lurking but now I'll bite.

I prefer Stephen's charter proposal.

The DTN-RG has produced some great work, and 5050 is a useable protocol, but it has well-documented issues that I believe are better addressed by a re-engineering of the solution taking into account the good work done by other IETF WGs and industry.  I'm not sure whether you want to call that a '5050bis' or a '5050 v2', and I am not advocating discarding the baby with the bath-water.

But (off the top of my head):
MIME-types work, let's re-use them.
Endpoint ID's are just not defined sufficiently.  There must be work in the area of addressing, particularly if there is a desire for a 'DTN of DTNs' and for interoperability with traditional networks.
SDNV's are a pain for developers.  There are alternatives that are easier to work with, e.g. VarInts from Google protocol buffers.
String dictionaries are a premature optimisation.  If you want compression, then compress.

I'm not going to go as far as Stephen and suggest that 'the web' has all the answers, and I'm not a big fan of text/ASCII protocols as I come from an embedded systems background, but a lot of good thought has gone into the ongoing development of HTTP, SMTP and others that should not be discounted.

In conclusion, I'm not going to suggest verbiage, but I would like to see the charter stating the work should be done to produce a new bundle envelope protocol, built on the experience of developing 5050, that addresses the issues around naming, encoding, content handling, forwarding and security.

Rick Taylor
The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. Airbus DS Limited Registered Office: Quadrant House, Celtic Springs, Coedkernew, Newport , NP10 8FZ. Registered in England and Wales under company number 04191036

---

From: Sebastian Schildt <[email-masked]>
Date: Tue, 9 Sep 2014 12:35:25 +0200

Hi Rick,

I would agree and disagree. As in: I think the points you mentioned are valid, but I see changing them feasible with the "modify-and-polish" approach advocated by a majority here.

> MIME-types work, let's re-use them.
I would argue that maybe MIME-types are a higher level of abstraction than what I would for a basic DTN protocol, but surely there would be nothing to prevent integration of MIME-types in to the FC5050 concept as it is.

> Endpoint ID's are just not defined sufficiently.  There must be work in the area of addressing, particularly if there is a desire for a 'DTN of DTNs' and for interoperability with traditional netwo…
Oh yes, I agree definitely.  But the problem is not that the current RFC5050 ran in the wrong direction and gut stuck with it approach, it rather is that it did not specify much t all in this regard. RFC5050 basically says "EID are... strings... Oh, and basically  routing is your problem not mine" So RFC5050bis/V2/X should extend on this. But again, this is just extending and getting more focus into RFC5050, not starting over based on lessons learned

> SDNV's are a pain for developers.  There are alternatives that are easier to work with, e.g. VarInts from Google protocol buffers.
I do not particularly like them. But they are manageable. Even on 8 Bit µCs. Are they too bad? I don't know. Compare this to MIME Encoding of binary data in mails It sucks and is inefficient, but it works.

> String dictionaries are a premature optimisation.  If you want compression, then compress.
It was my impression, that there is a consensus this is on the way out and will not be part of an upcoming RFC5050 evolution

> In conclusion, I'm not going to suggest verbiage, but I would like to see the charter stating the work should be done to produce a new bundle envelope protocol, built on the experience of developin…

So basically I think you are already in favor of the charter as it is shaping up now. The goal, as I understand it, is not to remain binary-compatible with the current RFC5050 specification. It is about addressing identified problems, changing the current protocol in reasonable ways such that existing knowledge is still valid, and existing implementations can be adapted more easily than starting all over again with an unknown beast of which no one knows if it will shape up to be a magic unicorn or Cthulhu himself.

MfG

Sebastian

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 09 Sep 2014 11:53:30 +0100

On 09/09/14 11:35, Sebastian Schildt wrote:
> The goal, as I understand it, is not to remain
> binary-compatible with the current RFC5050 specification. It is about
> addressing identified problems, changing the current protocol in
> reasonable ways such that existing knowledge is still valid, and
> existing implementations can be adapted more easily 

That last is implicit in Marc's charter, but is not explicitly
stated. Maybe it ought be though, since it'd add some more
clarity. Speaking personally, I don't think its that important
here since none of the code bases is that widely used and we
will be making backwards incompatible changes. (But maybe I'm
just fed up wrestling with DTN2:-) It is of course entirely
normal that other maintainers of 5050 code would prefer more
minimal change.

But even if current implementations were put into maintenance
mode, we don't lose the knowledge. I would argue that by using
that knowledge to develop a more easily developed and deployed
successor to 5050, we'd be putting that knowledge to a much
better use compared to developing a minimal 5050bis. (Note: that
is not a generic argument, but is specific to this particular
case based on what I've seen in the last decade of work on DTN
and others can reasonably disagree.)

> than starting all
> over again with an unknown beast of which no one knows if it will
> shape up to be a magic unicorn or Cthulhu himself.

Yes, that's the pejorative language thing again. It still
doesn't help though, does it? ;-)

S.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 9 Sep 2014 16:23:16 +0000

Hi Rick,

> From: dtn [mailto:[email-masked]] On Behalf Of Taylor, Rick
> Sent: Tuesday, September 09, 2014 3:08 AM
> To: Stephen Farrell; Marc Blanchet
> Cc: Scott Burleigh; [email-masked]
> The DTN-RG has produced some great work, and 5050 is a useable protocol, but it has well-documented
> issues that I believe are better addressed by a re-engineering of the solution taking into account the
> good work done by other IETF WGs and industry.  I'm not sure whether you want to call that a '5050bis'
> or a '5050 v2', and I am not advocating discarding the baby with the bath-water.
> 
> Endpoint ID's are just not defined sufficiently.  There must be work in the area of addressing,
> particularly if there is a desire for a 'DTN of DTNs' and for interoperability with traditional
> networks.

A DTN is an overlay over one or more Internets. DTN endpoint IDs are
DTN-layer identifiers that are mapped to the underlying IP addresses,
I guess via late binding. For a DTN of DTNs, it is not clear that an
endpoint ID would require a network part and an interface identifier
part the way IP addresses are architected because of the way the
mapping is done. My AERO proposal is an example where millions of
singleton node IDs can be mapped to an underlying IP addressing
realm and with no need for network prefixes.

What this would require for DTN would be an intergalactic DTN ID
delegation authority - perhaps a role IANA could take on. Also,
an intergalactic mapping system or routing system. But, not
necessarily a need for the DTN node ID to include a network
prefix part.

Thanks - Fred

> I'm not going to go as far as Stephen and suggest that 'the web' has all the answers, and I'm not a
> big fan of text/ASCII protocols as I come from an embedded systems background, but a lot of good
> thought has gone into the ongoing development of HTTP, SMTP and others that should not be discounted.
> 
> In conclusion, I'm not going to suggest verbiage, but I would like to see the charter stating the work
> should be done to produce a new bundle envelope protocol, built on the experience of developing 5050,
> that addresses the issues around naming, encoding, content handling, forwarding and security.
> 
> Rick Taylor
> The information contained within this e-mail and any files attached to this e-mail is private and in
> addition may include commercially sensitive information. The contents of this e-mail are for the
> intended recipient only and therefore if you wish to disclose the information contained within this e-
> mail or attached files, please contact the sender prior to any such disclosure. If you are not the
> intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the
> sender and inform them of the error and delete the e-mail, including any attached files from your
> system. Airbus DS Limited Registered Office: Quadrant House, Celtic Springs, Coedkernew, Newport ,
> NP10 8FZ. Registered in England and Wales under company number 04191036
>