Elwyn,
been there, tried to do that. The layering of bundle over HTTP gets messy
fast, and you need full very stateful gateways between bundle and bundle
over http doing reassembly...
That's why we came up with http-dtn:
https://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery
http://sat-net.com/L.Wood/dtn/http-dtn.html
which avoids bundling issues entirely. Not gained traction in DTNRG,
which was ultimately focused on the bundle protocol as a transport.
I spent quite a bit of time on the SAIL project looking at how to
integrate an RFC5050 based DTN instantiation of the netinf ICN scheme
with its instantiation(s) over HTTP and UDP. There were various
practical issues that made this much more difficult than it ought to
have been (partially due to incomplete (or more accurately, absent)
implementations of extension blocks in the DTN2 API) but more
fundamentally, issues with the whole extension block story - knowing
what had been sent whether or not security/integrity was used - and
generally difficulties trying to integrate the DTN model with the HTTP
model.
Lloyd Wood
lloyd(_dot_)wood(_at_)yahoo(_dot_)co(_dot_)uk
http://about.me/lloydwood
On Wednesday, 22 October 2014, 21:34, Elwyn Davies
<elwynd(_at_)folly(_dot_)org(_dot_)uk> wrote:
H, Will.
From your input and others that worked the N4C project, I deduce the same.
There doesn't appear to be a push to continue work on RFC5050. It is fine if
it happens. Individuals have offered to help out within the bounds of their
workloads, but they don't appear to be pushing for this.
From my perspective, I don't think that those of us who worked on N4C want to
abandon the bundle protocol concept, but, as Stephen has intimated, N4C and
other terrestrial projects have identified some problems with the RFC5050
implementation of the concept some of which go in different directions from the
problems mentioned in the WG BOF discussions.
I spent quite a bit of time on the SAIL project looking at how to integrate an
RFC5050 based DTN instantiation of the netinf ICN scheme with its
instantiation(s) over HTTP and UDP. There were various practical issues that
made this much more difficult than it ought to have been (partially due to
incomplete (or more accurately, absent) implementations of extension blocks in
the DTN2 API) but more fundamentally, issues with the whole extension block
story - knowing what had been sent whether or not security/integrity was used -
and generally difficulties trying to integrate the DTN model with the HTTP
model.
I also know that we don't have a useful practical terrestrial routing protocol
- something that bit N4C and SAIL.
So I can see why RFC 5050 per se is at a halt, but that doesn't mean an
improved instantiation of the bundle concept that integrated more easily with
the well-connected Internet wouldn't be an interesting research topic.
Regards,
Elwyn
Sent from my ASUS Pad
William Ivancic <ivancic(_at_)syzygyengineering(_dot_)com> wrote:
As far as my comments regarding US Army (these are the guys evaluation DTN):
How about deductive reasoning rather thancitation. If I recall correctly there
has been little if any input from the US Army or those who worked on DTN for
them such as the BBN folks in the past year or two on any of the DTN list
including this one. Thus, my conclusion is that they do not appear to be
pushing for continued work on RFC5050.
From your input and others that worked the N4C project, I deduce the same.
There doesn't appear to be a push to continue work on RFC5050. It is fine if
it happens. Iindividuals have offered to help out within the bounds of their
workloads, but they don't appear to be pushing for this.
This is my perspective, but it is not based on rumor, rather observation.
Granted, they say appearances can be deceiving. But then again, they may not
be.
Will
________________________________
From: Stephen Farrell <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: William Ivancic <ivancic(_at_)syzygyengineering(_dot_)com>; Martin
Stiemerling <mls(_dot_)ietf(_at_)gmail(_dot_)com>; Lloyd Wood
<lloyd(_dot_)wood(_at_)yahoo(_dot_)co(_dot_)uk>; "iab(_at_)iab(_dot_)org"
<iab(_at_)iab(_dot_)org>; "iesg(_at_)ietf(_dot_)org"
<iesg(_at_)ietf(_dot_)org>; "dtn(_at_)ietf(_dot_)org"
<dtn(_at_)ietf(_dot_)org>; "ietf(_at_)ietf(_dot_)org"
<ietf(_at_)ietf(_dot_)org>
Sent: Tuesday, October 21, 2014 8:46 PM
Subject: Re: [dtn] proposed DTN workgroup - what is process being followed?
Hi Will,
On 22/10/14 00:46, William Ivancic wrote:
Correction:
Correction: forgot the NOT between 'do' and 'appear'. Changes the
meaning significantly.
So, the original proponents of DTN such as the US Army and those
other than the Space Community such as the those working the N4C
project do NOT appear to be pushing for continued work on RFC5050, I
think, mainly due to difficulty in real world deployments.
Citation? I'm not aware of any. If there are no citations due
to a lack of public release then I'd be as critical of basing
a decision on that as I was about the lack of use-case detail
supplied by folks who do want the new WG. Decisions here ought
not be based on rumour which is what your statement about the
US army ends up as in the absence of citations or real details
I'm afraid.