Re: [dtn] proposed DTN workgroup - what is process being followed?

[Kevin Fall <[e-mail]>]

Thanks for the reminder...

One other difference between the ICN approaches and the BP design is
that BP supports the ability for bundles to be stored for extended
periods of time on devices without clocks or computing capabilities
(USB drives, carrier pigeon paper messages, writing on the wall).  The
decision to have clocks roughly sync'd ensures this is possible.

- Kevin

On Wed, Oct 22, 2014 at 5:09 PM, Lloyd Wood
<[e-mail]> wrote:
>
>> Also worthy of mention I think, is to remember that there are
>> differences between so-called 'problems' in the DTN design and goals
>> versus problems in the BP implementation(s) that most folks have
>> played with.  It would be unfortunate to conclude certain things as
>> 'problems' in the approach if they are not.
>
> Oh, indeed. Perfectly reliable equipment with reliable synchronised
> clocks can always be assumed and expected, but how that comes to pass
> is merely an implementation detail that is of no concern to a designer.
>
> The Bundle Protocol works far better when it's not actually run in a DTN.
>
> Lloyd Wood
> [e-mail]
> http://about.me/lloydwood
>
>
> On Thursday, 23 October 2014, 6:27, Kevin Fall <[e-mail]> wrote:
>
>
> Based on a meeting I recently attended and 2014 references such as this:
>
> (http://nsrc.cse.psu.edu/talks_2014/thoughts_on_future_army_waveforms_20Mar2014.pdf)
>
> I cannot share your conclusion.
>
> Also, and perhaps more architecturally interesting, I think it would
> be stretch to conclude that the ICN body of work covers the DTN work
> entirely.  Some of the differences I covered in the document you
> referenced.  But in short, here are a couple of observations regarding
> the differences:
>
> ICN is a groups of different projects, not one particular one, so
> there are some differences
> Generally the ICN projects refer to storage as short/immediate term
> (in-memory), not persistent
> DTN-style registrations, which can be persistent, are also not
> ordinarily in the ICN work
> ICN projects do not appear to deal with 1-directional links, at least
> not all of them
> The (two) goals of fragmentation in DTN are absent in the ICN designs
> Security was separated out in the BP for DTN; some of the ICN designs
> it is required/integral
> [but one needs to be careful here about what is being protected--
> content integrity/confidentiality]
>
> Also worthy of mention I think, is to remember that there are
> differences between so-called 'problems' in the DTN design and goals
> versus problems in the BP implementation(s) that most folks have
> played with.  It would be unfortunate to conclude certain things as
> 'problems' in the approach if they are not.
>
> regards,
> - Kevin
>
>
> On Tue, Oct 21, 2014 at 7:46 PM, William Ivancic
> <[e-mail]> 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.
>>
>>
>> ________________________________
>> From: William Ivancic <[e-mail]>
>> To: Martin Stiemerling <[e-mail]>; Lloyd Wood
>> <[e-mail]>; "[e-mail]" <[e-mail]>; "[e-mail]"
>> <[e-mail]>; "[e-mail]" <[e-mail]>; "[e-mail]"
>> <[e-mail]>
>> Sent: Tuesday, October 21, 2014 11:38 AM
>> Subject: Re: [dtn] proposed DTN workgroup - what is process being
>> followed?
>>
>> While the current  core DTN RFC5050 specification has a number of know
>> problems  that could be corrected  or eliminated (e.g., requirement for
>> rough time synchronization, no CRC, no hop count requirement to eliminate
>> routing loops), I think ICN may already have overtaken DTN RFC5050 for any
>> type of wide-scale deployment.  A close look at the two technologies seems
>> to indicate that ICN can do pretty much everything DTN can do and has
>> already had greater experimentation.  The few things that RFC5050 address
>> that ICN has not specifically addressed appear to be .....?
>>
>> I was going to say 1-way links, super long delays, and persistence, but I
>> think that is simply deployment specific.
>>
>> Kevin Fall actually has a nice comparison here:
>> http://kfall.net/ucbpage/talks/lcn-icn-dtn-keynote.pdf
>>
>> IMHO, ICN has a much better fragmentation strategy with the ability to
>> reassemble.
>>
>> Of course if RFC5050 is improved, you still need all the glue to make it
>> useful on a large scale (routing, security, network management, etc.)  as
>> Wes has already pointed out.
>>
>> The other thing that continues to trouble me is the thought that "There is
>> sufficient community interest to move this forward."  So far I have seen
>> NASA, JPL and Boeing.  But I have only seen seen interest in Space
>> deployment with is the realm of CCSDS.  I haven't seen real interest from
>> anyone else - particularly the US Army.  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.
>>
>> While I am willing to help fix the know problems with the current RFC5050
>> specification, I highly doubt there will be much large scale deployment
>> outside the space community.  So why IETF rather than CCSDS?
>>
>> Will
>>
>> ________________________________
>> From: Martin Stiemerling <[e-mail]>
>> To: Lloyd Wood <[e-mail]>; "[e-mail]" <[e-mail]>;
>> "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]>;
>> "[e-mail]" <[e-mail]>
>> Sent: Tuesday, October 21, 2014 6:08 AM
>> Subject: Re: [dtn] proposed DTN workgroup - what is process being
>> followed?
>>
>> Hi Lloyd,
>>
>> Thanks for sharing your concerns and see my replies in the text below:
>>
>> Am 18.10.14 um 16:27 schrieb Lloyd Wood:
>>>
>>>
>>>
>>> I see that the Hawaii IETF 91 agenda is out:
>>> https://datatracker.ietf.org/meeting/91/agenda.txt
>>> This lists a DTN WG meeting on the Thursday.
>>
>> It is listed as a WG, as it is expected to be a WG by the start of the
>> IETF-91 meeting. Right now, DTN is still in the stage of a proposed
>> Working Group, i.e., the final decision if there will be a DTN working
>> group is still to be made.
>>
>> The draft charter for external review has just been sent out on 10/22.
>>
>>>
>>> I am somewhat puzzled by this, as I was under the impression that
>>> discussion of whether to form a DTN workgroup or not was still underway;
>>> I thought it was currently blocked.
>>> https://datatracker.ietf.org/doc/charter-ietf-dtn/ballot/
>>
>> The charter is not blocked anymore, as the concerns in the IESG got
>> resolved.
>>
>> I am not sure how to arrive at the impression that the formation of a
>> DTN WG is blocked in principle. My personal impression from the BOF
>> session at IETF-90 in Toronto was and still is that there is sufficient
>> community interest, including multiple vendors that would build on top
>> of the DTN protoocls, in moving forward to standardize the DTN protocols.
>>
>> This is also noted in the meeting minutes and I did double-check the
>> audio recordings of the session:
>> http://www.ietf.org/proceedings/90/minutes/minutes-90-dtnwg
>> http://www.ietf.org/audio/ietf90/ietf90-tudor78-20140723-1520-pm2.mp3
>>
>>
>> There is sufficient community interest to move this forward, though
>> there is no clear plan on how the technical issues for each protocol
>> should be addressed. However, the technical issues do not need to be
>> addressed in the BOF - that is the task of the WG to be formed.
>>
>> There have been a number of discussions on the DTNWG mailing list about
>> the charter scope and the wording, plus an additional call to clarify
>> open issues. The output was the charter on the list that was sent to the
>> me as AD and sent to the IESG, modulo tweaks suggested by me.
>>
>>
>>> I see that concerns about technical direction were raised - but really,
>>> if it's technically the wrong direction for the proposed group to take,
>>> does having consensus even help? If it's believed to be technically
>>> wrong, isn't that a BLOCK?
>>>
>>> This second DTN workgroup discussion is after a first DTN BOF for a
>>> proposed WG at IETF 90, based on the idea of pushing the problematic
>>> IRTF Bundle Protocol onto standards track. That was told to go away and
>>> rethink the idea, and has proposed a slightly reworded charter... based
>>> on pushing the problematic IRTF Bundle Protocol onto standards track.
>>> The basic intent under the wordsmithing is unchanged, as far as I can
>>> see.
>>
>> Stephen also expressed his concerns that extending or keep using the
>> bundle protocol is his opinion problematic. This can be the case, but
>> apparently a community has interest in moving forward with the current
>> DTN protocols and standardize them.
>>
>>>
>>> In case I've missed the whole review process and the
>>> we're-forming-a-DTN-WG-huzzah celebration, I'd just like to remind
>>> everyone that I had some serious and well-thought-out objections to the
>>> previous
>>> we're-pushing-the-problematic-IETF-Bundle-Protocol-onto-standards-track
>>> charter for the proposed WG.
>>>
>>> Now that the charter has been revised to be a slightly different
>>> we're-pushing-the-problematic-IETF-Bundle-Protocol-onto-standards-track
>>> charter, those objections are still entirely valid, as far as I can see.
>>>
>>> I'm in the fortunate position of being outside the US govt program
>>> world, and not being funded to work on the Bundle Protocol or by anyone
>>> who thinks bundling is a great idea, so I'm able to offer actual
>>> concrete opinions. No conflict of interest.
>>>
>>> My concerns break down into:
>>>
>>> - Political - CCSDS thinks the Bundle Protocol is theirs, and has
>>> already modified the RFC5050 Bundle Protocol further to suit its needs
>>> in their Blue Book and ancillary protocols that haven't been documented
>>> in the IRTF or IETF. Thus, either an IETF DTN WG denies that existence,
>>> or has to cooperate with them - and since CCSDS is the only real Bundle
>>> Protocol user, forced cooperation it is. Which means modifying anything
>>> already codified in the CCSDS standards will be very difficult; the aim
>>> will be to push what is there through as a standard, problems or no.
>>
>> Concerns about CCSDS using the bunde protocol were raised quite early
>> and I am in contact with them to find out where any issues are and how
>> we can forward. The right thing to do, will be to send a liaison
>> statement from the DTNWG to CCSDS given that the WG is established.
>>
>>>
>>> - Procedural - I haven't seen any discussion of how this political
>>> cooperation of two very different standards bodies can be made to work
>>> in practice, and previous history (CCSDS making SCPS diverge from the
>>> TCP/IP base) suggests it won't; divergence without benefit for the IETF.
>>> How can a protocol be both CCSDS blue book and IETF standards track,
>>> when two different groups are pulling it in two different directions?
>>> Who has authority and change control?
>>
>> The owner of the protocol has change control and in the case of the DTN
>> protocols the current protocol specifications are owned by the IRTF. It
>> is always diffculty if there are branches of the protocol spec which are
>> not reported and/or ported back to the protocol owner.
>>
>> I see this as a diffcult point, but not a show stopper. This will need
>> serious work on both ends, but I can see that either side, i.e., CCSDS
>> and IETF, will do their share.
>>
>>>
>>> - Technical. The Bundle Protocol has some well-documented problems.
>>> Fixing those while also pushing for standards track and coordinating
>>> with CCSDS, which will raise already-standard and installed-based
>>> concerns, frankly seems impossible.
>>
>> This can be a tough point, but there are two choices: do nothing or
>> start working on a solution.
>>
>> We will see what the outcome is.
>>
>>>
>>> http://www.ietf.org/mail-archive/web/dtn/current/msg00043.html
>>> http://www.ietf.org/mail-archive/web/dtn/current/msg00054.html
>>> http://www.ietf.org/mail-archive/web/dtn/current/msg00187.html
>>> has some expansion on this, and our 'Bundle of Problems' paper lists a
>>> number of things, while giving a basic tutorial on how you would design
>>> a transport protocol for difficult environments, that haven't been fixed
>>> in the DTNRG's Bundle Protocol in the five years since that paper was
>>> published.
>>>
>>> - Luminal. These should hopefully be enlightening.
>>>
>>> So, can someone please say what process and milestones/dates are being
>>> followed here. If this is still in the process of making a decision,
>>> where is it, exactly?
>>
>> We follow the regular WG chartering process. There is now a proposed
>> working group with a draft charter for external review and comment. The
>> final decision if the WG will be chartered or not has not been made yet.
>>
>> Thanks,
>>
>>  Martin
>>
>>
>> _______________________________________________
>> dtn mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dtn
>>
>>
>>
>>
>>
>> _______________________________________________
>> dtn mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dtn
>>
>
>