Subject: [dtn] IETF DTNWG Comments on drafts and operations

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Tue, 21 Jul 2015 15:47:20 +0000

I read the drafts in preparation for tomorrow's meeting. There are still a number of open issues are probably should be discussed before we settle on the base protocol and how it's implemented. Each of the issues raised should
should probably be discussed as individual threads.

Thread 1

 I believe there needs to be a document or a section and RFC 5050bis  that explains default operations and assumptions.

What is a default route? Or, if a route doesn't exist and the bundle has an expired should be forwarding agent hold onto that bundle as a route may become available in the future?

 Is there an assumed limit to a bundle size? This affects queue management and most certainly the CRC check size currently specified in RFC 50-50bis draft.

 If a bundle agent successfully receives a bundle is it expected to do its best afford it? This begs the question "is custody really needed? Does it buy you anything?"

Thread 2

Should the network management portion of the bundle protocol be separated out from the base protocol? This will allow both to revolve separately and should simplify the base protocol. Most of the administrative
bundles seem to be part of network management.

 Thread 3

 Do we really need time as part of the base protocol? As previously noted under work with the DTN research group, few if anybody really knows how to set , bundle lifetime.  Nearly everyone I've spoken to or communicated with has set on the lifetime to some default relative to their system. The application has not set the bundle lifetime. Then result is all bundles have the same lifetime and queues are managed first in first out as generally all bundles have been set the same size as well. I wouldn't expect  this to be the case if large-scale deployments ever come into existence.

Creation time and bundle lifetime, in my honest opinion, make the protocol very fragile and are not needed. I believe it would be easier to manage bundles via queuing priorities whereby you had granularity's such as: forward immediately, hold for no longer than a minute, hold for no longer than an hour, day, week, indefinite. If one truly wants the creation time, an extension block could be used for that.

(Scott,  do you know how the ISS payloads will be setting DTN bundle lifetime?  Is it a default.)

Thread 4

Regarding the current draft for RFC5050bis:

 Hop count is a MUST.   As such, why not put it in the primary block instead of as an extension block?

The CRC's specified appear to be far too small for large bundles such as gigabyte size bundles.

Although there's a lot of discussion in the draft on fragmentation, any discussion on reactive fragmentation and how it interacts with security appears to be avoided. This really needs to be ironed out here so that the security protocol can be developed properly.

---

From: Kevin Fall <[email-masked]>
Date: Wed, 22 Jul 2015 04:19:39 -0400

A few thoughts/comments:

T1: agree that somewhere defaults should be discussed; don't know if it has
to be in 5050b or not
(consider the likes of RFC1122)

I don't think 'default route' is quite the right concept here.  There may
be no route for a next-hop or there may be an existing route but for which
transmission is scheduled later.  Neither of these really exist in IP.
IMHO, a node should in general always hold a bundle for which it doesn't
know what to do next just now, up to the expiration. [or possibly some net
mgmt determined limit]

any size limit and any corresponding integrity check probably merits
further discussion

no, I think custody still matters.  For example, I may wish to choose a
totally different route (e.g., that is longer but with more custodians) for
some traffic than for other traffic.  It is another concept we don't quite
have in IP.  (but it is a bit like mail MTAs).

T2: mostly this question is related to what do you always to ensure is
present in an implementation.  ICMP in IP is "for network management" in
some sense, and indeed many of the messages are no longer used, but there
are a couple of key ones that seem important (e.g., echo, redirect, dest
unreachable).  [interesting that 'destination unreachable' is kind of
interesting in a dtn world].

T3: we in general would set the bundle lifetime in the application.  For
some it isn't so obvious what to set it to.  (similar situation occurs for
trying to set the QoS/CoS).  However, just because its not always clear
what to use, I believe there are significant use cases where it is
important, and it helps resource management in a world where data can
reside in the network persistently.  Queue priority is really for  a
different issue, and relates more to the priority/CoS tagging.

T4: could you please justify the "MUST" claim?  There seem to be several
cases where it doesn't matter  much (e.g., p2p links), cases in which
routing loops (over time) are desired, in which there are inherently
loop-free topologies.

agree with the reactive fragmentation comment.

regards,
- Kevin

On Tue, Jul 21, 2015 at 11:47 AM, Ivancic, William D. (GRC-LCA0) <
[email-masked]> wrote:

>  I read the drafts in preparation for tomorrow's meeting. There are still
> a number of open issues are probably should be discussed before we settle
> on the base protocol and how it's implemented. Each of the issues raised
> should
>   I believe there needs to be a document or a section and RFC 5050bis
>  that explains default operations and assumptions.
>
>  What is a default route? Or, if a route doesn't exist and the bundle has
> an expired should be forwarding agent hold onto that bundle as a route may
> become available in the future?
>
>   Is there an assumed limit to a bundle size? This affects queue
> management and most certainly the CRC check size currently specified in RFC
> 50-50bis draft.
>
>   If a bundle agent successfully receives a bundle is it expected to do
> its best afford it? This begs the question "is custody really needed? Does
> it buy you anything?"
>
>  Thread 2
>
>  Should the network management portion of the bundle protocol be
> separated out from the base protocol? This will allow both to revolve
> separately and should simplify the base protocol. Most of the
> administrative
>   Do we really need time as part of the base protocol? As previously
> noted under work with the DTN research group, few if anybody really knows
> how to set , bundle lifetime.  Nearly everyone I've spoken to or
> communicated with has set on the lifetime to some default relative to their
> system. The application has not set the bundle lifetime. Then result is all
> bundles have the same lifetime and queues are managed first in first out as
> generally all bundles have been set the same size as well. I wouldn't
> expect  this to be the case if large-scale deployments ever come into
> existence.
>
>  Creation time and bundle lifetime, in my honest opinion, make the
> protocol very fragile and are not needed. I believe it would be easier to
> manage bundles via queuing priorities whereby you had granularity's such
> as: forward immediately, hold for no longer than a minute, hold for no
> longer than an hour, day, week, indefinite. If one truly wants the creation
> time, an extension block could be used for that.
>
>  Although there's a lot of discussion in the draft on fragmentation, any
> discussion on reactive fragmentation and how it interacts with security
> appears to be avoided. This really needs to be ironed out here so that the
> security protocol can be developed properly.
>
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
>
>

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 22 Jul 2015 14:46:15 +0200

Some thoughts below:

On 21/07/2015 17:47, Ivancic, William D. (GRC-LCA0) wrote:
> I read the drafts in preparation for tomorrow's meeting. There are 
> still a number of open issues are probably should be discussed before 
> we settle on the base protocol and how it's implemented. Each of the 
> issues raised should
Some of this is RFC 4838 for the assumptions.  I am not sure what other 
things are needed at the moment - but yes, if there are defaults they 
need to be in the document
>
> What is a default route? Or, if a route doesn't exist and the bundle 
> has an expired should be forwarding agent hold onto that bundle as a 
> route may become available in the future?
Default route isn't really a useful concept especially for an 
opportunistic DTN network.  The default for a sensor network is more 
likely to be 'epidemic' - give it to anything that goes past.
> management and most certainly the CRC check size currently specified 
> in RFC 50-50bis draft.
There is currently an implied potential limit due to the constraints on 
SDNVs that need to be turned back into integers - no requirement to 
support SDNVs for more than 64 bit integers.
> its best afford it?
'afford'?  There are various things that a BPA might do. Whether these 
are desirable is another matter.  It could refuse it on policy grounds, 
such as it was 'too old' and the node is short on memory so it might be 
unlikely that it would be delivered in time.  It could decide that the 
bundle is large and it is running low on battery and trying to relay it 
later would unduly compromise other things it has to do.    It could 
dislike the sender or the destination and refuse to be a relay (being 
selfish or petty rather than actively malicious).  It could certainly 
decide at a later date that the 'old' or 'not enough energy' tests apply 
and discard it later. REQUIRING it to be more generous is unlikely to be 
realistic.
> This begs the question "is custody really needed? Does it buy you 
> anything?"
Yes, I believe it does - it 'contracts' the node to give the bundle 
better treatment - but of course there is no guarantee that it can 
deliver as with any other node.
> bundles seem to be part of network management.
I agree with Kevin's comment on this.  Some things *have* to be 
implemented.  There are a whole lot of stuff that you can do without but 
really ought to be handled by a separate DTN protocol (rather than 
manual configuration, etc).
> noted under work with the DTN research group, few if anybody really 
> knows how to set , bundle lifetime.  Nearly everyone I've spoken to or 
> communicated with has set on the lifetime to some default relative to 
> their system. The application has not set the bundle lifetime. Then 
> result is all bundles have the same lifetime and queues are managed 
> first in first out as generally all bundles have been set the same 
> size as well. I wouldn't expect  this to be the case if large-scale 
> deployments ever come into existence.
The BPA and/or the applications ought to pro-actively monitor how long 
bundles take to get to their destinations and use this information to 
inform their lifetime settings.  Administrative reports can supply this 
information.  One thing that is missing in DTN2 is a way to push this 
information back to applications.  This is probably something we should 
be adding to 5050bis.
> protocol very fragile and are not needed. I believe it would be easier 
> to manage bundles via queuing priorities whereby you had granularity's 
> such as: forward immediately, hold for no longer than a minute, hold 
> for no longer than an hour, day, week, indefinite. If one truly wants 
> the creation time, an extension block could be used for that.
(Creation time, sequence number) are currently the 'unique identifier' 
for the bundle.  You would need to replace them with something else if 
creation time went away.
> instead of as an extension block?
Justification? I'm not convinced either.  There are certainly cases 
where it is essentially irrelevant (e.g., epidemic 'routing')
> Although there's a lot of discussion in the draft on fragmentation, 
> any discussion on reactive fragmentation and how it interacts with 
> security appears to be avoided. This really needs to be ironed out 
> here so that the security protocol can be developed properly.
Agreed.

Regards,
Elwyn

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Wed, 22 Jul 2015 12:51:52 +0000

If a bundle agent successfully receives a bundle is it expected to do its best afford it?
'afford'?  There are various things that a BPA might do. Whether these are desirable is another matter.  It could refuse it on policy grounds, such as it was 'too old' and the node is short on memory so it might be unlikely that it would be delivered in time.  It could decide that the bundle is large and it is running low on battery and trying to relay it later would unduly compromise other things it has to do.    It could dislike the sender or the destination and refuse to be a relay (being selfish or petty rather than actively malicious).  It could certainly decide at a later date that the 'old' or 'not enough energy' tests apply and discard it later.  REQUIRING it to be more generous is unlikely to be realistic.

Should have read:  If a bundle agent successfully receives a bundle is it expected to do its best to forward it?  (Own proofreader and using dictation to try and save some time.  Missed that one.  Sorry.)

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Wed, 22 Jul 2015 12:57:43 +0000

Hop count is a MUST.   As such, why not put it in the primary block instead of as an extension block?
Justification? I'm not convinced either.  There are certainly cases where it is essentially irrelevant (e.g., epidemic 'routing')

If you have a routing loop in the DTN layer for whatever reason, the bundle will bounce around until terminated somehow.  I believe the current mechanism is Bundle Lifetime.  Test this by putting the bundle lifetime to 300 years and come back later to see if it is still bouncing around.  Note, I've experience this with manets but the hop count will terminate the packet.  Also, depending on the implementation, one may not even check the lifetime before forwarding if a route exists.

Will