Joe,
Thank you for your comments on our responses (and please note I just posted a -09). While I appreciate that we should not significantly hold up the doc, we could clarify what we mean when we say “architecture”.
Very much agree that this is not a functional architecture. And we did not intend for it to be that.
Would it help to add a paragraph up front that talks about the value of a *logical* architecture, what a logical architecture addresses, and then map those pieces to the sections of the document? I understand there are still opinions on the level of detail around logical flows, but I think what we have qualifies as a logical architecture and that it does have value as an informational document.
-Ed
Edward J. Birrane, III, Ph.D. (he/him/his)
Chief Engineer, Space Networking
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (C) 443-690-8272
From: touch@xxxxxxxxxxxxxx <touch@xxxxxxxxxxxxxx>
Sent: Friday, January 26, 2024 11:32 AM
To: Birrane, Edward J. <Edward.Birrane@xxxxxxxxxx>
Cc: tsv-art@xxxxxxxx; draft-ietf-dtn-dtnma.all@xxxxxxxx; dtn@xxxxxxxx; last-call@xxxxxxxx
Subject: Re: [Tsv-art] [EXT] [dtn] Tsvart last call review of draft-ietf-dtn-dtnma-08
APL external email warning: Verify sender touch@xxxxxxxxxxxxxx before clicking links or attachments
Hi, Ed,
Notes below.
Overall, I still feel this is more a doc about issues such an architecture might address than an architecture itself. If that’s the case, then changing the doc perspective might be appropriate.
However, that’s more my individual opinion than something that should hold the doc.
Joe
—
Dr. Joe Touch, temporal epistemologist
On Jan 19, 2024, at 10:08 AM, Birrane, Edward J. <Edward.Birrane@xxxxxxxxxx> wrote:
Joe, TSVART,
Thank you for taking the time to review this informational document and to provide comments on where we can clarify or improve the work.
My replies are in-line below. To help with discussion, I tried to enumerate comments so replies are prefaced with "EJB_#" where # is the comment I am responding to.
To summarize, we would propose 3 changes to the existing document, to clarify intent:
1. Clarify this informational document does not imply an implementation OR an implementation architecture (EJB_4)
2. Remove unused terms from the terminology section (EJB_5)
3. Define the term "timely" based on its use in the document (EJB_6) and use the term to clarify end-to-end where appropriate (EJB_8).
-----
First, it claims to focus on operating devices in challenged environments, but
does not specifically rely on DTN protocols. That seems to imply that DTN
protocols would not be sufficient, which begs some questions – if DTN is not
useful here (the very case for which it seems to have been designed), why
not?
EJB_1: The document does not mean to imply that DTN protocols (namely BP) are insufficient and we try to address this in the document. For example, the abstract states: "This document describes a DTN management architecture (DTNMA) suitable for managing devices in any challenged environment but, in particular, those communicating using the DTN Bundle Protocol (BP)" and the introduction states: "The DTNMA is designed to leverage any transport, network, and security solutions designed for challenged networks. However, the DTNMA should operate in any environment in which the Bundle Protocol (BPv7) [RFC9171] is deployed."
EJB_1: Would it help clarify this if we make a statement such as we would expect there to be a BP transport binding?
Wouldn’t that binding be (with BP) a DTN protocol?
It would help to understand an example case where devices are operated in challenged environments but would not need DTN protocols, as indicated.
If not DTN, then what transport would work?
EJB_2: Reference implementations have used bundle (BPv6 and BPv7) and also UDP, TCP, and others. There was a proposal to use RMAP for transport in a very particular circumstance. BPv7 should be used in the cases where BPv7 is helpful. But locking the DTNMA architecture to BPv7 is unnecessary.
If a TCP or UDP can be used, why would we consider these devices operating in challenged environments?
Or are these devices intended to be used to support devices in OTHER challenged environments, but this management architecture might not itself be in a challenged environment? (e.g., within devices of a single enclave).
Second, the implication that this system is useful in the presence of
unidirectional links alone or that it never relies on query/response strains
credibility. If there is never a return path, then commands might never be
received or executed, at which point there’s not much utility here.
EJB_3: We may not be using the term "link" in the same way. This document uses the term link to imply a single-hop. As such, a uni-directional link does not imply there is no return path. For example, the topology A->B->C->A is a series of uni-directional links which allow bi-directional communications between A and C. Similarly the time-variant topology A->C...time passes...C->A is also a series of uni-directional links which allow bi-directional communication.
EJB_3: Since such topologies do exist in deployed systems it was important for us to mention that we can run over uni-directional links.
Ahh - it might be useful to similarly highlight the need for bidirectional paths, even if time-discontinuous.
Sec 1.2
- The definition of Reference Model might be more explicit that it does
not imply an implementation architecture.
EJB_4: Since this is an informational document we felt this would be understood. In section 1.3 we describe the reference model as follows: "a reference model that can be used to reason about the DTNMA independent of an implementation".
EJB_4: Would it be clarifying to correct this to say "independent of an implementation or implementation architecture.”?
It might be useful to add that briefly in the abstract or earlier in Sec 1.
Sec 2
- if TBR is a simplification of SBR, does that imply that the rule
stimulus is exclusively relative or absolute time (and thus not dependent on
other state?) - If TBR is a simplification of SBR, it would be useful to
include time, which is not obviously included in the internal state of a DA
EJB_5: Good catch. The discussion around the terms TBR and SBR were moved from this document to a subsequent document (from WG review) but the terms erroneously remained here in the terminology section. Generally, any terms in the terminology section that are not used in the document should be removed.
OK. It might be useful to check that in the other doc then.
Sec 3.1
- Does the lack of round trip communications within a given time imply
that there might never be a time when this could complete? It would be
useful to be specific either way (either eventually available or nor eventually
available).
EJB_6: In any network a node may cease to function, of course. The "given time" referred to here (and when we say "timely" in the document) refers to timelines needed to support synchronous request-response architectures - such as mentioned in Section 6 when discussing open-loop control.
EJB_6: We can add a definition of the term "timely" in the terminology section to help clarify.
That would be useful, IMO.
This section should address whether there are any assumptions about
message reordering, loss, or duplication.
EJB_7: We felt that (while important) these are characteristics of implementation architectures and transport mechanism (both out of scope for this document, from the scope section). However, we can add a sentence/bullet to this section to emphasize the importance of considering the impact of message transport on any future implementation architecture.
That would be useful as well, IMO.
End-to-end paths are described as whether they
exist at a given time; this implies something equivalent to a horizontal line in
a space-time diagram, where the paths may exist in a way useful to
conventional protocols as long as they follow end-to-end diagonals along a
light-cone; this description should be tightened-up, especially given such
cases are common in cases where DTN is intended to be used
(interplanetary)
EJB_8: I agree that causally-connected events in a space-time diagram can be used to clarify constraints related to signal propagation. But relatively-close (pun intended?) nodes within a light-cone may fail to meet performance requirements as a function of configuration. Heartily agree that there is good reasoning to be done here, but an informational network management architecture is not likely the appropriate vehicle for that.
EJB_8: Suggest we tighten the language here to use the term "timely" (which I suggested adding in EJB_6) and discuss "timely end-to-end".
That would be useful, IMO.
Sec 3.2
- The topological aspects appear to imply each link is point-to-point,
rather than (potentially) multipoint bidirectional or asymmetric (multipoint in
one direction; unicast in the other).
EJB_9: We did not intend this, and do not believe any wording here prevents something other than point-to-point.
It might be useful to point that out in a couple of places, just to avoid assumptions to the contrary.
Sec 3.2.1
- This section should discuss the potential need for idempotency, i.e.,
operations that can be executed multiple times with the same result as being
executed exactly once. These can include state-dependent operations as
well as
inherently indempotent operations. - That issue should be carried into
section 9.5 on command execution.
EJB_10: Understand and agree that idempotency is important in an implementing architecture - and that there are multiple ways of achieving this. We felt it was better to address this in the context of implementing architecture (e.g. *not* in this document). Currently other work being discussed in the DTNWG does, for example, include language on idempotency.
Idempotency is as much an aspect of the archecture as ‘eventually synchronous’, IMO. I.e., from an architecture viewpoint, noting that not everything needs a confirmation or explicit duplicate rejection to allow retries ‘in the blind’. It might help if it could be mentioned as affecting the final design.
Sec 3.2
- There should be far more management implications noted here,
including
the potential need for idempotency if commands need to be re-issued
before a confirmation is received. That has implications on the command
structure as
well as its execution. - This section appears to imply eventual
bidirectional communication, again this is not consistent with some of the
front-matter.
EJB_11: As an informational document we tried to limit this to the set of implications that do not otherwise imply an implementation (the importance of which is noted in a prior comment).
See above; AFAICT, it’s useful to note.
EJB_11: Also the discussion on bi-directional communication is, I think, resolved from comment EJB_3.
Agreed.
Sec 3.3
- Again, the notion of one-way management is not useful if exactly as
presented; there appears to be the need for eventual confirmation, which
should be noted
EJB_11: I think we addressed the concept of "one-way" management in comment EJB_3. Discussions of related questions such as command timing, command coordination across large numbers of nodes, etc... are considered to be functions of an implementation and implementation architecture.
Agreed; fixed above.
Sec 7
- Although this is the core, it is more of a list of useful properties
than a true architecture. - A architecture should describe the
components, the interfaces between them, and their individual function,
describing how they combine to provide a capability. That does not appear
to be the case here; this is more like a survey of the possible components,
but there doesn’t appear to be enough information here to design a system.
EJB_12: We felt this was the appropriate level of detail for an informational document.
As an architecture, IMO this doc needs to explain the necessary aspects of each interface, even if it doesn’t detail the design or implementation of that interface.
I.e., something that makes this an architecture, not “aspects of an architecture that another doc might describe”.
Sec 8
- The capability appears to be described in sec 8, which seems like it
should come before the decomposition in this section.
Sec 9
- This model appears to be the core of the architecture, more so than the
component list in Sec 7; it might be useful to move this earlier.
Sec 10
- Use cases define the model’s aggregate intended behavior, i.e., the
target. As such, this might be useful to explain before Sec 9, before Sec 7,
and before Sec 8.
EJB_13: Regarding the ordering of sections 8,9,10 - we feel the ordering from less-to-more specific is preferred, but could also add cross-citation if that would make the material clearer to understand.
That would help. Agreed this might have multiple possible organizations.
Sec 12
- This section seems far too brief; the earlier sections that discuss
security issues should be cross-cited in extended discussions here.
EJB_14: We feel this is the appropriate depth as this is an informational document. Subsequent material built from this would require significantly more detail.
See two answers above; again, IMO, more info is needed to make this an architecture discussion, not a discussion about what a future architecture document might consider.
Sec 13
- If this architecture truly has only one notable reviewer, it might be
useful to distribute it more widely and obtain more feedback. The fact that all
authors and the only notable reviewer are all from the same organization
also begs the question “who is this for”? Has no other party or organization
contributed to it at all?
EJB_15: This work has been briefed in the DTNWG, with members outside of the DTNWG, with members outside of the IETF, and there exist reference implementations to this architecture in multiple organizations. We do not see that information as important content of this informational document.
It would be useful to add that, esp. in the intro. Examples from some of these implementations might be the way to address some of my concerns about this not being an architecture.
Or, if this is really “discussions about possible such architectures”, shift the doc to have that perspective…
Joe
-Ed
---
Edward J. Birrane, III, Ph.D. (he/him/his)
Chief Engineer, Space Constellation Networking
Supervisor, Embedded Applications Group
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839
_______________________________________________
Tsv-art mailing list
Tsv-art@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tsv-art
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
