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 <ivancic(_at_)syzygyengineering(_dot_)com>
To: 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 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 <mls(_dot_)ietf(_at_)gmail(_dot_)com>
To: 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 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
dtn(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/dtn
_______________________________________________
dtn mailing list
dtn(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/dtn