Subject: [dtn] Review of draft-dowdell-dtnwg-static-00 on static routing

From: Elwyn Davies <[email-masked]>
Date: Wed, 22 Jul 2015 13:47:19 +0200

Hi.

I'm afraid this is going to be rather destructive (and a bit late for 
today's meeting) - sorry!

Abstract:  Talking about IP addresses and RFC 1812 is irrelevant and 
confusing in the context of DTN.  There is no guarantee that a DTN node 
will have an IP address at all.  Nodes are identified by one or more 
Endpoint IDs which are defined by RFC 5050bis to be in the form of a 
URI.  All DTN routing is name based.

General: Convergence layer specification in routes:  I am afraid I 
hadn't been paying enough attention to the early part of the discussion 
on static routing in the mailing list.  Will suggested back in about the 
second message in the Static Routing thread that a route needs to 
specify the convergence layer. I totally disagree. For a start it is a 
major layer violation.  Routing knows nothing about the convergence 
layer and shouldn't need to care.  Routing should be able to assume that 
the bundle will arrive initially at whatever next hop it decides on and 
ultimately at a destination that matches the destination Endpoint ID.  
What convergence layer the BPA uses to pass the bundle between nodes is 
irrelevant.    I cannot see why routing cares about what convergence 
layer is used.  Please delete all mention of convergence layer and 
convergence layer adaptors from the draft.

s2:  Expanding the definitions of terminology in a draft that doesn't 
actually define the item is very dangerous:  there is a significant 
chance that the definitions are or become incompatible if both documents 
are in development.  Personally I think that it is sufficient at most to 
refer to the original definition (in this case in the new BP draft) and 
possibly pick out any features that are relevant to routing. Thus:
Bundle: Point out that routing needs the destination Endpoint ID. There 
might be a bit more if anybody actually gets around to using minimum 
reception groups.  Some forms of routing might possibly care about the 
source Endpoint ID as well.  Otherwise the information in the bundle and 
why we use bundles is not relevant.
Bundle Payload:  routing doesn't care.   None of the variants are used 
in the draft outside the definition, so it can be removed.
Node/Bundle Protocol Agent: We don't need to know about implementation 
details.  All that matters is that a DTN node contains at least one BPA  
and DTN (static) routing is a capability provided by (some) nodes with BPAs
Convergence Layer Adapator: Delete (see above).
Bundle Endpoint:  It is unwise to provide yet another definition of 
Bundle Endpoints.  We already have three slightly differerent ones in 
RFC 4838, RFC 5050 and draft-dtnwg-bp-00.
Forwarding:  My definition of forwarding says: forwarding is what a node 
carrying a bundle does when it has a connection or link to another node 
and the routing capability decides that the bundle should be copied 
across to the node at the other end of the connection.  The details 
about minimum reception group etc are things that the routing capability 
has to understand in order to decide whether a bundle should be 
forwarded.  The bundle will arrive at its destination(s) after one or 
more forwardings.  I'll write about  minimum reception groups later.
Transmission:  In my view this is not a useful term.  The first part of 
it just subverts a part of the routing capability - but this is a wider 
discussion.

s3 and RFC 1812:  Apart from the fact that RFC 1812 is pretty archaic, 
static routing in a connection-wise, topologically (generally) stable 
network and in an often topologically unstable DTN network are very 
different propositions.  I think that pointing people at RFC 1812 will 
result in people getting the wrong ideas. DTN static routing needs to be 
defined independently.

"Network Prefix": DTN doesn't use IP addresses internally and late 
binding means that the whole 'address aggregation' discussion is not 
relevant to DTN.   Mentioning network prefices is a red herring and 
confusing.

s3 and Convergence Layers:  A route MUST NOT (IMO) require a specific 
type of CLA.  By definition, all CL's can transfer a valid bundle 
between nodes.  Nothing else is needed by the routing system and it goes 
against the principles of DTN to try to constrain the type of CLA used 
in forwarding a bundle.

The mechanisms used in the DTN2 reference implementation are a useful 
starting point.  Routes are defined in terms of either (destination, 
waypoint, metric) or (destination, link, metric) triples where the link 
is effectively an explicit next hop.  These are held in the 'static 
routing table'.

If an opportunistic connection with node with EID 'nexthop' registered 
occurs, a temporary (nexthop, opportunistic link, metric) triple is 
added to the routing table.  Then a recursive algorithm can be applied 
for each destination in a bundle waiting to be dispatched to find a 
chain of waypoints leading from the destination to a currently connected 
nexthop.  The bundle can then be sent via the link associated with the 
next hop on the route.  In principle, if there are multiple routes, the 
metric can be used to discriminate.  However in sparse networks multiple 
concurrent routes are the exception and DTN2 never implemented use of 
the metric. Exactly how one would combine the metrics of the waypoint 
routes requires more thought.  More details of this process can be found 
in Sections 4.8 and 4.8.2 of 
http://www.n4c.eu/Download/n4c-wp2-023-dtn-infrastructure-fs-12.pdf. 
Note the pattern matching that is done.

---

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

>major layer violation.

Agreed.  I was thinking "Static Route" but for DTN that probably only
makes sense for a connected system. Basically for "Static Route" you
better know exactly what you are doing.

Will

---

From: "Juan A. Fraire" <[email-masked]>
Date: Wed, 22 Jul 2015 11:42:26 -0300

Dear All,

I agree that keeping CLA details separated from routing allows for a better
stack architecture; however this might derive in insufficient information
for some situations. In particular, there are specific scenarios where a
node can see another node by means of two or more different CLAs
simultaneously. This tend to happen in multi-transponder DTN satellite
systems, where ignoring the CLA might result in incorrect forwarding.

Specifically, since the only difference between these simultaneous contacts
is the underlying CLA, there is no way to enforce nor guarantee the node
will send the data through a specific link. IMO, to avoid this forwarding
issue, there must be enough information in the (destination, link, metric)
triplet in order to distinguish and eventually multiplex among several
underlying link layers, and hence CLAs.

Regards,

J.Fraire

On Wed, Jul 22, 2015 at 9:36 AM, Ivancic, William D. (GRC-LCA0) <
[email-masked]> wrote:

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

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 23 Jul 2015 01:01:13 +0000

I think there's a general issue here.  In my view, a large part of the strength of the DTN architecture is that it is not monolithic: the machinery is in place to delegate quite a lot of processing responsibility from the BPA to the CLAs, and I think we err when we don't seize those delegation opportunities.

The most familiar example is late binding, i.e, fine-grained routing that is entirely private to the CLA.  When a bundle is to be forwarded over a TCP/IP hop of the end-to-end path, we don't expect the BPA to tell IP how to forward the bundle through the Internet, router by router, to the proximate BP destination node; we leave that to IP.

Likewise, the best guarantor of reliability in forwarding over any single hop of the end-to-end path is usually the reliability provided by the CLA for that hop, e.g., TCP retransmission, LTP retransmission, hop-specific erasure coding, etc.  The CLA operates a protocol that is designed for the distinctive characteristics of that hop and is virtually always more competent at dealing with those peculiarities than BP can be.

In the meeting today we briefly discussed the question of where to decide the time at which an outbound bundle is to be forwarded.  Clearly there may be routing policy concerns that are time-dependent, and it is surely the responsibility of the BPA to observe those concerns.  But I think that as soon as any time-dependent constraints on the forwarding of the bundle along the selected route have been removed, the decision as to the exact moment at which the bundle should be presented to the link layer for radiation is best made by the CLA that has direct interfaces to the link.  Building that sort of convergence-layer infrastructure awareness into the BPA would unnecessarily inflate the BPA (in addition to being a layer violation).

Returning to late binding: we have already established that the BPA relies on the CLA for what we might term "low-level" routing.  So I would suggest that the same principle applies to the multi-transponder DTN satellite system problem. That is, I think it's a mistake to require the BPA to be smart enough to make transponder selection decisions on the satellite mesh hop(s) of an end-to-end path.  Certainly you have to implement that decision-making logic, but why slather it onto the implementation of BP, supposedly the "thin waist" of the DTN architecture?  Implement the transponder selection logic in the implementation of the satellite mesh CLA.  Let BP decide which BP node the bundle should go to next (that is, do BP routing), and then let the (single) satellite mesh CLA decide which transponder to use to get it there via the satellite mesh.

I suspect we unconsciously tend to think that if X is a DTN operations issue then X has to be addressed by BP, the core protocol of DTN.  I believe that kind of thinking leads to bloated, fragile, and ultimately unworkable infrastructure. I have been there, and I would rather not go there again.

Scott
________________________________
From: dtn [[email-masked]] on behalf of Juan A. Fraire [[email-masked]]
Sent: Wednesday, July 22, 2015 7:42 AM
To: Ivancic, William D. (GRC-LCA0)
Cc: Elwyn Davies; John Dowdell; DTN WG
Subject: Re: [dtn] Review of draft-dowdell-dtnwg-static-00 on static routing

Dear All,

I agree that keeping CLA details separated from routing allows for a better stack architecture; however this might derive in insufficient information for some situations. In particular, there are specific scenarios where a node can see another node by means of two or more different CLAs simultaneously. This tend to happen in multi-transponder DTN satellite systems, where ignoring the CLA might result in incorrect forwarding.

Specifically, since the only difference between these simultaneous contacts is the underlying CLA, there is no way to enforce nor guarantee the node will send the data through a specific link. IMO, to avoid this forwarding issue, there must be enough information in the (destination, link, metric) triplet in order to distinguish and eventually multiplex among several underlying link layers, and hence CLAs.

Regards,

J.Fraire

Will

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

---

From: "Juan A. Fraire" <[email-masked]>
Date: Thu, 23 Jul 2015 12:33:45 -0300

Thanks Scott for the explanation. Actually, relaying all non-DTN specific
logic to CLA makes a lot of sense to me and is the way we see it in
our Agency. However, when dealing with static routing metrics, such as data
rate or contact volume (as we do in CGR), you cannot just divide waters so
easily because you are assuming that the underlying CLA will deliver that
throughput (which in our case implies a selection).

A general case of our transponder selection problem is a DTN node A
connected to two different networks (through their specific CLAs) both of
which in turn lead to a DTN node B. IMHO, defining a single entry for A-B
can result problematic since each contact A-B can have a different routing
metric. Furthermore, I would not know how the BPA can decide to which CLA
deliver the bundle since two of them reaches the same destination. I might
be missing something here though...

Thanks,

J.Fraire

On Wed, Jul 22, 2015 at 10:01 PM, Burleigh, Scott C (312B) <
[email-masked]> wrote:

>  I think there's a general issue here.  In my view, a large part of the
> strength of the DTN architecture is that it is not monolithic: the
> machinery is in place to delegate quite a lot of processing responsibility
> from the BPA to the CLAs, and I think we err when we don't seize those
> delegation opportunities.
>
>  The most familiar example is late binding, i.e, fine-grained routing
> that is entirely private to the CLA.  When a bundle is to be forwarded over
> a TCP/IP hop of the end-to-end path, we don't expect the BPA to tell IP how
> to forward the bundle through the Internet, router by router, to the
> proximate BP destination node; we leave that to IP.
>
>  Likewise, the best guarantor of reliability in forwarding over any
> single hop of the end-to-end path is usually the reliability provided by
> the CLA for that hop, e.g., TCP retransmission, LTP retransmission,
> hop-specific erasure coding, etc.  The CLA operates a protocol that is
> designed for the distinctive characteristics of that hop and is virtually
> always more competent at dealing with those peculiarities than BP can be.
>
>  In the meeting today we briefly discussed the question of where to
> decide the time at which an outbound bundle is to be forwarded.  Clearly
> there may be routing policy concerns that are time-dependent, and it is
> surely the responsibility of the BPA to observe those concerns.  But I
> think that as soon as any time-dependent constraints on the forwarding of
> the bundle along the selected route have been removed, the decision as to
> the exact moment at which the bundle should be presented to the link layer
> for radiation is best made by the CLA that has direct interfaces to the
> link.  Building that sort of convergence-layer infrastructure awareness
> into the BPA would unnecessarily inflate the BPA (in addition to being a
> layer violation).
>
>  Returning to late binding: we have already established that the BPA
> relies on the CLA for what we might term "low-level" routing.  So I would
> suggest that the same principle applies to the multi-transponder DTN
> satellite system problem. That is, I think it's a mistake to require the
> BPA to be smart enough to make transponder selection decisions on the
> satellite mesh hop(s) of an end-to-end path.  Certainly you have to
> implement that decision-making logic, but why slather it onto the
> implementation of BP, supposedly the "thin waist" of the DTN architecture?
> Implement the transponder selection logic in the implementation of the
> satellite mesh CLA.  Let BP decide which BP node the bundle should go to
> next (that is, do BP routing), and then let the (single) satellite mesh CLA
> decide which transponder to use to get it there via the satellite mesh.
>
>  I suspect we unconsciously tend to think that if X is a DTN operations
> issue then X has to be addressed by BP, the core protocol of DTN.  I
> believe that kind of thinking leads to bloated, fragile, and ultimately
> unworkable infrastructure. I have been there, and I would rather not go
> there again.
>
>  Scott
>  ------------------------------
> *From:* dtn [[email-masked]] on behalf of Juan A. Fraire [
> [email-masked]]
> *Sent:* Wednesday, July 22, 2015 7:42 AM
> *To:* Ivancic, William D. (GRC-LCA0)
> *Cc:* Elwyn Davies; John Dowdell; DTN WG
> *Subject:* Re: [dtn] Review of draft-dowdell-dtnwg-static-00 on static
> routing
>
>   Dear All,
>
>  I agree that keeping CLA details separated from routing allows for a
> better stack architecture; however this might derive in insufficient
> information for some situations. In particular, there are specific
> scenarios where a node can see another node by means of two or more
> different CLAs simultaneously. This tend to happen in multi-transponder DTN
> satellite systems, where ignoring the CLA might result in incorrect
> forwarding.
>
>  Specifically, since the only difference between these simultaneous
> contacts is the underlying CLA, there is no way to enforce nor guarantee
> the node will send the data through a specific link. IMO, to avoid this
> forwarding issue, there must be enough information in the (destination,
> link, metric) triplet in order to distinguish and eventually multiplex
> among several underlying link layers, and hence CLAs.
>
>  Regards,
>
>  J.Fraire
>
>
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 24 Jul 2015 04:06:23 +0000

Hi, Juan.  I see your point, and I agree that there may be cases where multiple alternative CLAs could be used to convey a bundle to its proximate destination (next-hop) node, and in those cases the BPA needs some basis on which to make its CLA selection.  What bothers me is the prospect of using information exposed by the CLAs as that basis; I think it's a slippery slope that leads to the BPA poking its nose into convergence layer business, blurring responsibilities and inflating the BPA.

So long as the BPA is making its decisions on the basis of bundle protocol information, BP node information, hints provided to the BPA by the application, etc., I think we are on firm ground.  And I guess if there is a clean, generic interface that CLAs can use to provide their own hints to the BPA, that too may be reasonable; I admit that I am a layerist at heart, but I recognize that caution over "layer violation" can be taken too far.

What concerns me is scope creep.  I think the general principle of dividing work into relatively simple tasks with well-defined interfaces is in the long run the only way to manage the increasing diversity and complexity of network operations.

Scott
________________________________
From: Juan A. Fraire [[email-masked]]
Sent: Thursday, July 23, 2015 8:33 AM
To: Burleigh, Scott C (312B)
Cc: Ivancic, William D. (GRC-LCA0); Elwyn Davies; John Dowdell; DTN WG
Subject: Re: [dtn] Review of draft-dowdell-dtnwg-static-00 on static routing

Thanks Scott for the explanation. Actually, relaying all non-DTN specific logic to CLA makes a lot of sense to me and is the way we see it in our Agency. However, when dealing with static routing metrics, such as data rate or contact volume (as we do in CGR), you cannot just divide waters so easily because you are assuming that the underlying CLA will deliver that throughput (which in our case implies a selection).

A general case of our transponder selection problem is a DTN node A connected to two different networks (through their specific CLAs) both of which in turn lead to a DTN node B. IMHO, defining a single entry for A-B can result problematic since each contact A-B can have a different routing metric. Furthermore, I would not know how the BPA can decide to which CLA deliver the bundle since two of them reaches the same destination. I might be missing something here though...

Thanks,

J.Fraire

On Wed, Jul 22, 2015 at 10:01 PM, Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>> wrote:
I think there's a general issue here.  In my view, a large part of the strength of the DTN architecture is that it is not monolithic: the machinery is in place to delegate quite a lot of processing responsibility from the BPA to the CLAs, and I think we err when we don't seize those delegation opportunities.

Scott
From: dtn [[email-masked]<mailto:[email-masked]>] on behalf of Juan A. Fraire [[email-masked]<mailto:[email-masked]>]

Dear All,

Regards,

J.Fraire

Will