Re: [dtn] [Tsv-art] [EXT] Tsvart last call review of draft-ietf-dtn-dtnma-08

[Zaheduzzaman Sarker <[e-mail]>]

Hi Ed.,

Being explicit about "logical" architecture would help. Please propose text
and later update the draft accordingly.

//Zahed

On Fri, Jan 26, 2024 at 6:53 PM Birrane, Edward J. <
[e-mail]> wrote:

> 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:* [e-mail] <[e-mail]>
> *Sent:* Friday, January 26, 2024 11:32 AM
> *To:* Birrane, Edward J. <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: [Tsv-art] [EXT] [dtn] Tsvart last call review of
> draft-ietf-dtn-dtnma-08
>
>
>
> *APL external email warning: *Verify sender [e-mail] 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
>
> www.strayalpha.com
>
>
>
> On Jan 19, 2024, at 10:08 AM, Birrane, Edward J. <
> [e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tsv-art
>
>
>