Subject: [dtn] BOF Inputs

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Wed, 23 Jul 2014 17:13:32 +0000

( I hope to participate remotely today.  I may have to sign off early due to escort commitments. )

In no particular order, here are my concerns and comments regarding IETF taking on DTN as a working group.

The DTN research group activity is nearly zero over the past few years.  Why would we expect people to expend energy on an IETF standard if they haven’t done the necessary work in the IRTF – routing, simulations, demonstrations on any reasonable scale, etc.

Boeing says they want a standard, but will not say anything about scale or use cases.

I hear build it and they will come.  I don’t buy that.

“IETF protocols started with small deployments and build from there.” True, but in the beginning, IETF was a research group. Only later did the research become standards.  IRTF was formed to take on the research aspects of what IETF originally did.  Thus, IRTF is where the research should be done.  IMHO, there are numerous areas of research that have not been adequately addressed. Just a few open issues that need research with many others available:  Does custody transfer buy you anything?  Should bundles be treated like packets or like packages (aggregated or deaggregate?)  Is time necessary at all?  Can RFC505 scale with a flat name space?   How does one route between scheduled and opportunistic domains?  How does one pick the best default route?

“Build it and let the community decide.”  But that takes time and effort that perhaps is better spent elsewhere.  Many of the DTN community have moved to Information Centric Networking.  IMHO ICN is likely to come up with better naming of objects (bundles) than DTN has done.

You don’t need a standard for someone to deploy.  Look at Skype.  Often the standard comes after a number of similar, but not interoperable applications (jabber, AOL chat, Yahoo chat).

NASA wants this, yet is not support IETF with people.  Only Scott Burleigh is physically present (I think).  It is my understanding that a large NASA meeting is taking place next week a Google for deployment of RFC5050.  But those people are not even on the BOF mail list.

NASA is going to attempt to deploy RFC5050 and wants it to operate at high speed (Gbps rates).  The main issue currently is for ISS to automate scheduling and autonomously handle data buffering during Loss of Signal.  ISS is not in constant contact with Mission Control or Payload Operations.  DTN is viewed as a solution.  They, NASA should learn a lot of what is good and bad for this particular scenario in the next few years.  Thus, making changes to RFC5050 at this time may be premature.  We are talking tens or less of DTN instances, so updating code should be relatively trivial.  We are not updating millions of systems in multiple domains.

If this is a Space only protocol, why isn’t it being done by CCSDS (Consultative Committee for Space Data Systems)?  Well, actually it is and is not.  They reference RFC5050 as the primary standard, but RFC5050 is not a standard, it is an experimental protocol specification. Finally, CCSDS has been working this for some time, yet still does not have an official specification. (For what it is worth, Keith Scott, CCSDS DTN working group chair does not appear to be on the BOF mail list either.)

Note, CCSDS is not open and is one organization, one vote.  And CCSDS work is done …. Not on open mail lists although I wouldn’t say it is done at the meeting either.  It is sort of done by closed groups who then present at the meetings. Also, I have colleagues in South America that would like to participate in any DTN improvements, but they cannot afford to travel to meetings and are not official members of CCSDS organizations (NASA, ESA, JAXA, others).  On the other hand, IETF has shied away from deployment specific protocols ever since TCPSAT – at least that is my understanding.

If a working group were formed, would we need a lesion to CCSDS?

Deployments have been extremely limited to date, but each deployment seem to point out more and more issues/problems.  When treating bundles as packets such as has been done for some space related file applications, then you find a need for payload conditioning to ensure information is place back in proper order.  With custody transfer, we find that custody aggregation becomes necessary in order to not congest a low-bandwidth back channel.

All in all, I would say RFC5050 is not ready for standards track and there is much research that needs to be done and should be done in IRTF.  Also, alternatives should be considered – particularly if you expect wide-spread deployment.

Some Items that are currently missing:  An actual problem statement, requirements statement and expectations of operation.  So, if an IETF working group is formed, I think you need the problem statement and requirements.  It the problem is just Space than this should be handled by CCSDS and not IETF.

Will Ivancic

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 23 Jul 2014 18:12:25 +0000

Hi Will,

Ø  Boeing says they want a standard, but will not say anything about scale or use cases.

Boeing will present a problem statement and use cases during the first presentation today.

Thanks - Fred

From: dtn [mailto:[email-masked]] On Behalf Of Ivancic, William D. (GRC-LCA0)
Sent: Wednesday, July 23, 2014 10:14 AM
To: [email-masked]
Subject: [dtn] BOF Inputs

The DTN research group activity is nearly zero over the past few years.  Why would we expect people to expend energy on an IETF standard if they haven't done the necessary work in the IRTF - routing, simulations, demonstrations on any reasonable scale, etc.

I hear build it and they will come.  I don't buy that.

"IETF protocols started with small deployments and build from there." True, but in the beginning, IETF was a research group. Only later did the research become standards.  IRTF was formed to take on the research aspects of what IETF originally did.  Thus, IRTF is where the research should be done.  IMHO, there are numerous areas of research that have not been adequately addressed. Just a few open issues that need research with many others available:  Does custody transfer buy you anything?  Should bundles be treated like packets or like packages (aggregated or deaggregate?)  Is time necessary at all?  Can RFC505 scale with a flat name space?   How does one route between scheduled and opportunistic domains?  How does one pick the best default route?

"Build it and let the community decide."  But that takes time and effort that perhaps is better spent elsewhere.  Many of the DTN community have moved to Information Centric Networking.  IMHO ICN is likely to come up with better naming of objects (bundles) than DTN has done.

You don't need a standard for someone to deploy.  Look at Skype.  Often the standard comes after a number of similar, but not interoperable applications (jabber, AOL chat, Yahoo chat).

If this is a Space only protocol, why isn't it being done by CCSDS (Consultative Committee for Space Data Systems)?  Well, actually it is and is not.  They reference RFC5050 as the primary standard, but RFC5050 is not a standard, it is an experimental protocol specification. Finally, CCSDS has been working this for some time, yet still does not have an official specification. (For what it is worth, Keith Scott, CCSDS DTN working group chair does not appear to be on the BOF mail list either.)

Note, CCSDS is not open and is one organization, one vote.  And CCSDS work is done .... Not on open mail lists although I wouldn't say it is done at the meeting either.  It is sort of done by closed groups who then present at the meetings. Also, I have colleagues in South America that would like to participate in any DTN improvements, but they cannot afford to travel to meetings and are not official members of CCSDS organizations (NASA, ESA, JAXA, others).  On the other hand, IETF has shied away from deployment specific protocols ever since TCPSAT - at least that is my understanding.

All in all, I would say RFC5050 is not ready for standards track and there is much research that needs to be done and should be done in IRTF.  Also, alternatives should be considered - particularly if you expect wide-spread deployment.

Will Ivancic