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

From: Lloyd Wood <[email-masked]>
Date: Sat, 18 Oct 2014 14:27:21 +0100

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.

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/
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.

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.

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

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

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?

thanks,

Lloyd Wood 
[email-masked] 
http://sat-net.com/L.Wood/dtn

---

From: Lloyd Wood <[email-masked]>
Date: Sat, 18 Oct 2014 15:27:12 +0100

thanks,

Lloyd Wood 
[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Sat, 18 Oct 2014 22:47:08 -0700

Lloyd,

Good question. It is customary that working groups being proposed to be created (like DTN is) are given a slot in the schedule. If the working group creation goes through before the meeting, the slot will be a regular working group meeting. If it does not go through, depending on circumstances we’d either run the meeting as a BOF or cancel it.

That was the process part. I’ll let others comment on the substance part of your comments.

Jari

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Sun, 19 Oct 2014 16:53:05 +0000

Engaging with Lloyd on matters relating to DTN has in the past proven to be a bottomless time sink.  In this instance, though, I worry that silence might be construed as endorsement of his remarks.  This would be incorrect; they are without merit.

The DTN BoF was not told to go away and rethink the idea.  The consensus of the BoF was "that the charter should be reviewed again to make it initially simpler".  As I recall, our responsible area director concurred.  That simplified charter is what was presented to IETF.

The charter simplifications were discussed on the dtn mailing list and in a conference call on 30 September.  In the course of those discussions the BoF also considered a radically different charter proposed by Stephen Farrell.  We concluded that the ideas in that charter had appeal but that there was not sufficient support in the BoF to address them in a working group.  Taking them up in the DTN Research Group was proposed, without dissent, except for speculation that there might not be sufficient energy in the RG either.

There are no "political" issues.  National space agencies needed the DTN protocols in their current form documented as CCSDS standards in the near term so that they could be used for long-range flight mission planning.  The CCSDS Bundle Protocol (BP) Blue Book is a profile of RFC 5050; it does not modify the Bundle Protocol.  Additional protocols are indeed defined in that book as well; if IETF determines that those protocols might also be useful in Internet DTN, then they too could be standardized for the Internet, but obviously CCSDS isn't going to "force" IETF to do anything whatsoever.  And the CCSDS standardization process easily accommodates revision; if IETF chooses to standardize the DTN protocols, the future CCSDS BP standard will almost certainly be a profile of the IETF BP standard just as the current CCSDS BP standard is a profile of RFC 5050.  NASA and other space agencies will surely have an interest in making sure that revisions to BP as it is standardized for the Internet don't diminish its utility in space flight operations, but I don't know of any resistance to this consideration within IETF.

Consequently there are no "procedural" issues.  Taking Lloyd's example: the CCSDS standardization of SCPS doesn't seem to have in any way degraded the operation of TCP/IP in the Internet.  That's because the deliberations of IETF are - and will certainly remain - completely distinct from those of CCSDS.

Again, NASA and other space agencies - like any other user community - will have an interest in preserving BP's utility in space flight operations as the protocol is revised during standardization.  This interest will be expressed through space agency employees' participation in the IETF DTN WG, just as the interests of user communities have always been expressed by their employees' participation in working groups.  There is nothing new here.

Finally, regarding technical issues: Lloyd characterizes the Bundle Protocol as "problematic", a restatement of the position taken in papers that he and several colleagues have written over the years.  In the Results section of his 2011 paper on "Assessing and improving an approach to delay-tolerant networking" (http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/CRS-2011/lloyd-wood-ccsr-crs-2011-dtn.pdf), for example, Lloyd identifies exactly three deficiencies:

(1)	Security is commonly not deployed, in part because of the complexity of the Bundle Security Protocol (BSP).  There seems to be rough consensus in the BoF that BSP is indeed too complex; a simplified BSP specification has been posted as an Internet Draft and a working prototype has been developed.

(2)	No data integrity check, apart from the keyed integrity checks defined in BSP, is included in the DTN architecture.  Adding such a check has long been identified as a proposed enhancement to BP, with no dissent within the BoF that I'm aware of.

(3)	Rough clock synchronization among machines hosting BP agents is required for some functions, but this is not possible in all circumstances.  Mitigation of this problem has likewise long been recognized as a candidate DTN WG work item, with no dissent within the BoF that I'm aware of; an Internet Draft addressing it was posted four years ago.

None of these issues have been significant enough to deter NASA from deployment of BP in International Space Station operations.  BP is not "problematic".

The frequently cited "Bundle of Problems" paper (2009) concludes with these words:

"We hope that recounting those problems here will lead to them being addressed in later versions of the DTN architecture and Bundle Protocol specifications, as research into delay-tolerant networking continues and these research ideas are matured. Once these are addressed, the Bundle Protocol may one day be ready for operational use."

While BP already is clearly ready for operational use, I believe the BoF welcomes the opportunity to further realize the hope expressed here by Lloyd and his co-authors.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Jari Arkko
Sent: Saturday, October 18, 2014 10:47 PM
To: Lloyd Wood
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn] proposed DTN workgroup - what is process being followed?

Lloyd,

Good question. It is customary that working groups being proposed to be created (like DTN is) are given a slot in the schedule. If the working group creation goes through before the meeting, the slot will be a regular working group meeting. If it does not go through, depending on circumstances we'd either run the meeting as a BOF or cancel it.

That was the process part. I'll let others comment on the substance part of your comments.

Jari

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 21 Oct 2014 12:08:53 +0200

Hi Lloyd,

Thanks for sharing your concerns and see my replies in the text below:

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

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

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

---

From: William Ivancic <[email-masked]>
Date: Tue, 21 Oct 2014 08:38:37 -0700

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 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 <[email-masked]>
To: Lloyd Wood <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Tuesday, October 21, 2014 6:08 AM
Subject: Re: [dtn] proposed DTN workgroup - what is process being followed?

Hi Lloyd,

Thanks,

   Martin

_______________________________________________
dtn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtn

---

From: William Ivancic <[email-masked]>
Date: Tue, 21 Oct 2014 16:46:28 -0700

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 <[email-masked]>
To: Martin Stiemerling <[email-masked]>; Lloyd Wood <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Tuesday, October 21, 2014 11:38 AM
Subject: Re: [dtn] proposed DTN workgroup - what is process being followed?

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.

Will

Hi Lloyd,

> IRTF
 Bundle Protocol onto standards track. That was told to go away and

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.

Thanks,

   Martin

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 Oct 2014 01:46:59 +0100

Hi Will,

On 22/10/14 00:46, William Ivancic wrote:
> 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.

In the case of N4C, you are incorrect to infer that others
involved in that project would have agreed with my alternative
proposal. We simply don't know as they've not spoken up. Its
also not correct to say that 5050 caused deployment difficulty
for N4C - it didn't really. (My own reasons for preferring a
different target differ form that, but were stated already in
this discussion.)

S.

---

From: William Ivancic <[email-masked]>
Date: Tue, 21 Oct 2014 18:47:33 -0700

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 <[email-masked]>
To: William Ivancic <[email-masked]>; Martin Stiemerling <[email-masked]>; Lloyd Wood <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Tuesday, October 21, 2014 8:46 PM
Subject: Re: [dtn] proposed DTN workgroup - what is process being followed?

Hi Will,

---

From: Kevin Fall <[email-masked]>
Date: Wed, 22 Oct 2014 15:27:49 -0400

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
<[email-masked]> wrote:
> 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.
>
>
> To: Martin Stiemerling <[email-masked]>; Lloyd Wood
> <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]"
> <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]"
> <[email-masked]>
> 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.
>
> 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
>
> To: Lloyd Wood <[email-masked]>; "[email-masked]" <[email-masked]>;
> "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>;
> "[email-masked]" <[email-masked]>

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 22 Oct 2014 22:09:27 +0100

> '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 
[email-masked] 
http://about.me/lloydwood

On Thursday, 23 October 2014, 6:27, Kevin Fall <[email-masked]> wrote:

regards,
- Kevin

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 22 Oct 2014 22:20:37 +0100

Scott,

You quote a two-page introductory summary paper (one of three of mine at that workshop) which get through ignoring end-to-end principle in a sentence, and doesn't even have space in the accepted format to e.g. get to custody transfer. There's a reason the 'Bundle of Problems' paper is more than ten pages.

Without merit? Given that it's taken years and Fred's drafts to convince you of the need for checksums, I'm not convinced that I'm the cause of the timesink.

Do you speak for CCSDS? I'm interested in the "National space agencies needed the DTN protocols" bit, and which tail is wagging which dog here. How is that need determined?

regards

Lloyd Wood 
[email-masked] 

On Monday, 20 October 2014, 3:53, "Burleigh, Scott C (312B)" <[email-masked]> wrote:

There are no "political" issues.  National space agencies needed the DTN protocols in their current form documented as CCSDS standards in the near term so that they could be used for long-range flight mission planning.  The CCSDS Bundle Protocol (BP) Blue Book is a profile of RFC 5050; it does not modify the Bundle Protocol.  Additional protocols are indeed defined in that book as well; if IETF determines that those protocols might also be useful in Internet DTN, then they too could be standardized for the Internet, but obviously CCSDS isn't going to "force" IETF to do anything whatsoever.  And the CCSDS standardization process easily accommodates revision; if IETF chooses to standardize the DTN protocols, the future CCSDS BP standard will almost certainly be a profile of the IETF BP standard just as the current CCSDS BP standard is a profile of RFC 5050.  NASA and other space agencies will surely have an interest in making sure that revisions to BP as
 it is standardized for the Inte
rnet don't diminish its utility in space flight operations, but I don't know of any resistance to this consideration within IETF.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Jari Arkko
Sent: Saturday, October 18, 2014 10:47 PM
To: Lloyd Wood
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn] proposed DTN workgroup - what is process being followed?

Lloyd,

Jari

---

From: Kevin Fall <[email-masked]>
Date: Thu, 23 Oct 2014 07:30:44 -0400

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

---

From: William Ivancic <[email-masked]>
Date: Thu, 23 Oct 2014 05:47:06 -0700

Hi Kevin,

Yes, I worked closely with this group.  Chart 19 says it all. Buy the way, don't confuse the need for DTN with the need for the Bundle protocol.  Chart 19 supports Wes' comments.  There is not way this group can deploy large networks without item 2.

Challenging network environment leads to link and network disruptions

	1. Need to develop a robust DTNbased transport service 
	2. Requires solutions to addressing, routing, management, discovery and forwarding/QOS
I have not seen this group actively participating on any of the DTN mail list in the past year or two or perhaps more.  Time flies. 

Will

________________________________
 From: Kevin Fall <[email-masked]>
To: William Ivancic <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; Martin Stiemerling <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; Lloyd Wood <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Wednesday, October 22, 2014 3:27 PM
Subject: Re: [dtn] proposed DTN workgroup - what is process being followed?

---

From: "Juan A. Fraire" <[email-masked]>
Date: Thu, 23 Oct 2014 11:10:51 -0300

Hi Will,

Where can I read (not slides) about how ICN handles routing, forwarding,
buffering, network-level congestion, and contact predictability? Is there
an RFC or good article about these?

Thanks,

J.Fraire
Universidad Nacional de Córdoba, Argentina

On Thu, Oct 23, 2014 at 9:47 AM, William Ivancic <
[email-masked]> wrote:

> Hi Kevin,
>
> Yes, I worked closely with this group.  Chart 19 says it all. Buy the way,
> don't confuse the need for DTN with the need for the Bundle protocol.  Chart
> 19 supports Wes' comments.  There is not way this group can deploy large
> networks without item 2.
>
>    1. Need to develop a robust DTN based transport service
> I have not seen this group actively participating on any of the DTN mail
> list in the past year or two or perhaps more.  Time flies.
>
> Will
>
>
>   ------------------------------
>  *From:* Kevin Fall <[email-masked]>
> *To:* William Ivancic <[email-masked]>
> *Cc:* "[email-masked]" <[email-masked]>; Martin Stiemerling <
> [email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <
> [email-masked]>; Lloyd Wood <[email-masked]>; "[email-masked]" <
> [email-masked]>
> *Sent:* Wednesday, October 22, 2014 3:27 PM
> *Subject:* Re: [dtn] proposed DTN workgroup - what is process being
> followed?
>
> (
> http://nsrc.cse.psu.edu/talks_2014/thoughts_on_future_army_waveforms_20Mar2014.pdf
> )
>

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Thu, 23 Oct 2014 14:52:35 +0000

Juan,

Remember,  we are not just discussing space applications. We are discussing general applications hundreds of millions of nodes.
Bundling may work well for your application in space with four or five nodes, but perhaps not so much for general Internet.  Remember IETF is INTERNET Engineering Task Force.  CCSDS is Space.  If IETF is going to work on something, it needs to address the general needs of the Internet user base, not just Space.  That is CCSDS' realm.

Will

A good overview:
https://www.youtube.com/watch?v=3zOLrQJ5kbU

Some papers are here with link to  presentations.
http://named-data.net/publications/

But above is just one viewpoint of ICN.  ICNRG should lead you to others.
https://irtf.org/icnrg

A publish/subscribe architecture is what BBN came up with for F6 (Fractionated Spacecraft)
http://dl.acm.org/citation.cfm?doid=2348616.2348626

Will
******************************
William D. Ivancic
Phone 216-433-3494
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

From: "Juan A. Fraire" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 23, 2014 10:10 AM
To: William Ivancic <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Kevin Fall <[email-masked]<mailto:[email-masked]>>, Martin Stiemerling <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Lloyd Wood <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn] proposed DTN workgroup - what is process being followed?

Hi Will,

Where can I read (not slides) about how ICN handles routing, forwarding, buffering, network-level congestion, and contact predictability? Is there an RFC or good article about these?

Thanks,

J.Fraire

On Thu, Oct 23, 2014 at 9:47 AM, William Ivancic <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kevin,

Will

________________________________
From: Kevin Fall <[email-masked]<mailto:[email-masked]>>
To: William Ivancic <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; Martin Stiemerling <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; Lloyd Wood <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, October 22, 2014 3:27 PM
Subject: Re: [dtn] proposed DTN workgroup - what is process being followed?

_______________________________________________
dtn mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dtn

---

From: "Juan A. Fraire" <[email-masked]>
Date: Thu, 23 Oct 2014 12:00:55 -0300

Thanks Will,

I'm aware of CCSDS/IETF raison d'etre. My thought is: If you guys say it is
good for millions of nodes, then it should be the same for 10s of them. I
just want to cross-check on that.

Thanks for the info :)

J.Fraire

On Thu, Oct 23, 2014 at 11:52 AM, Ivancic, William D. (GRC-LCA0) <
[email-masked]> wrote:

>   Juan,
>
>  Remember,  we are not just discussing space applications. We are
> discussing general applications hundreds of millions of nodes.
> Bundling may work well for your application in space with four or five
> nodes, but perhaps not so much for general Internet.  Remember IETF is
> INTERNET Engineering Task Force.  CCSDS is Space.  If IETF is going to work
> on something, it needs to address the general needs of the Internet user
> base, not just Space.  That is CCSDS' realm.
>
>  Will
>
>
>  A good overview:
>   From: "Juan A. Fraire" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Kevin Fall <[email-masked]>, Martin
> Stiemerling <[email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>, "
> [email-masked]" <[email-masked]>
>>  Yes, I worked closely with this group.  Chart 19 says it all. Buy the
>> way, don't confuse the need for DTN with the need for the Bundle protocol.  Chart
>>  I have not seen this group actively participating on any of the DTN
>> mail list in the past year or two or perhaps more.  Time flies.
>>
>>  Will
>>
>>

---

From: Kevin Fall <[email-masked]>
Date: Thu, 23 Oct 2014 12:49:18 -0400

Perhaps start here:

http://trac.tools.ietf.org/group/irtf/trac/wiki/icnrg

(removed posting to whole IETF).

- Kevin

On Thu, Oct 23, 2014 at 10:10 AM, Juan A. Fraire <[email-masked]> wrote:
> buffering, network-level congestion, and contact predictability? Is there an
> RFC or good article about these?
>
> Thanks,
>
>
> J.Fraire
> On Thu, Oct 23, 2014 at 9:47 AM, William Ivancic
>> Need to develop a robust DTN based transport service
>> Requires solutions to addressing, routing, management, discovery and
>> forwarding/QOS
>>
>> Cc: "[email-masked]" <[email-masked]>; Martin Stiemerling
>> <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]"
>> <[email-masked]>; Lloyd Wood <[email-masked]>; "[email-masked]"
>> <[email-masked]>