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:
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.wood@xxxxxxxxxxx
http://about.me/lloydwood
lloyd.wood@xxxxxxxxxxx
http://about.me/lloydwood
On Wednesday, 22 October 2014, 21:34, Elwyn Davies <elwynd@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx> wrote:
From: Stephen Farrell <stephen.farrell@xxxxxxxxx>
To: William Ivancic <ivancic@xxxxxxxxxxxxxxxxxxxxx>; Martin Stiemerling <mls.ietf@xxxxxxxxx>; Lloyd Wood <lloyd.wood@xxxxxxxxxxx>; "iab@xxxxxxx" <iab@xxxxxxx>; "iesg@xxxxxxxx" <iesg@xxxxxxxx>; "dtn@xxxxxxxx" <dtn@xxxxxxxx>; "ietf@xxxxxxxx" <ietf@xxxxxxxx>
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.
> 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@xxxxxxxxxxxxxxxxxxxxx> 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.farrell@xxxxxxxxx>
To: William Ivancic <ivancic@xxxxxxxxxxxxxxxxxxxxx>; Martin Stiemerling <mls.ietf@xxxxxxxxx>; Lloyd Wood <lloyd.wood@xxxxxxxxxxx>; "iab@xxxxxxx" <iab@xxxxxxx>; "iesg@xxxxxxxx" <iesg@xxxxxxxx>; "dtn@xxxxxxxx" <dtn@xxxxxxxx>; "ietf@xxxxxxxx" <ietf@xxxxxxxx>
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.