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

[William Ivancic <[e-mail]>]

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 doNOT 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