Hi Charles,
Thank you for the review and comments. I've published version -09 to address your comments. Please see detailed answers below.
Thanks,
Yingzhen
On Thu, Feb 29, 2024 at 12:19 PM Charles Perkins via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Charles Perkins
Review result: Ready with Nits
Overall, the document is readable and related to the subject matter
indicated in the title. The use cases are quite basic. Most of these
suggestions are intended to enhance readability and clarify possible
ambiguities or sources of confusion.
I think the two expansions of TVR clash badly, and should be avoided somehow,
but I don't know if that is feasible. For instance, this document could
possibly replace the more abstract idea of Time-Variant Routing TVR and
instead use TBR (Time-Based Routing). Besides that, the document describes
cases in which the routing depends on resource availability, not strictly based
on time of day. So maybe it could be called RBR (Resource-Based Routing) or
Time And Resource Based Routing (TRBR).
My comments below are prefaced by "!!CEP: ".
=====================================================
TVR (Time-Variant Routing) Use Cases
draft-ietf-tvr-use-cases-07
!!CEP: This TVR clashes with "Time-Based Validation and Revocation".
=====================================================
3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Routing Impacts . . . . . . . . . . . . . . . . . . . . . 6
3.3. Exemplar . . . . . . . . . . . . . . . . . . . . . . . . 6
!!CEP: maybe "exemplar --> exemplary network" throughout.
[Yingzhen]: As suggested by Paul Wouters, "exemplar" has been changed to "example".
4. Operating Efficiency . . . . . . . . . . . . . . . . . . . . 8
4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Routing Impacts . . . . . . . . . . . . . . . . . . . . . 9
=====================================================
4. Exemplars of a network conformant to the use case.
!!CEP: maybe "Exemplary networks".
[Yingzhen]: changed to "Example networks".
=====================================================
The use cases that are considered in this document are the following.
1. Resource Preservation (described in Section 3), where there is
on-off link availability over time at the client level. Time
!!CEP: maybe "information about link availability".
[Yingzhen]: thanks for the suggestion. Changed as suggested.
Variant Routing can utilize the predictability of the link
availability to optimize network connectivity by taking into
account end point resource preservation.
=====================================================
optimize the cost of the system exploitation. The notion of cost
of a path is extended by introducing the notion of its time-
varying characteristic.
!!CEP: more likely, the notion of cost is extended to be a time-dependent
function instead of a constant.
[Yingzhen]: Changed as suggested.
=====================================================
3. Dynamic Reachability (described in Section 5), where there is on-
off link availability variation between nodes taking part of the
!!CEP: maybe "information about link availability".
[Yingzhen]: changed as suggested.
end-to-end path. Time Variant Routing can exploit the
predictability of the link availability to optimize in-network
routing.
=====================================================
The document may not represent the full set of cases where time-
!!CEP: maybe "does not intend to represent".
[Yingzhen]: changed as suggested.
variant routing computations could beneficially impact network
performance - new use cases are expected to be generated over time.
Similarly, the concrete examples within each use case are meant to
=====================================================
environments or otherwise with limited internal resources.
Constraints such as available power, thermal ranges, and on-board
storage can all impact the instantaneous functionality of a node. In
!!CEP: maybe "instantaneous operation".
[Yingzhen]: changed as suggested.
particular, resource management on such a node can require that
certain functionality be powered on (or off) to extend the ability of
the node to participate in the network.
=====================================================
To manage on-board functionality as a function of available
resources, a node must understand certain elements of how resources
!!CEP: "understand" is too anthropomorphic.
[Yingzhen]: I've rewritten the sentence as the following:
"To effectively manage on-board functionality based on available resources, a node must comprehend specific aspects concerning the utilization and replenishment of resources."
=====================================================
are used and replenished. It is assumed that patterns of the
environment, device construction, and operational configuration exist
with enough regularity and stability to allow meaningful planning.
The following assumptions are made with this use case.
!!CEP: maybe "expected" instead of "assumed" in these paragraphs.
[Yingzhen]: Changed to "expected".
1. Known resource expenditures. It is assumed that there exists
some determinable relationship between the resources available on
=====================================================
place relating to the status of the node’s functional neighborhood.
During these times, forwarding to and from the node might be delayed
pending some synchronization.
!!CEP: Should mention the possibility of power reduction instead of simply
on-off operation.
[Yingzhen]: A power reduction may result in a link shut-down. I think it's addressed abstractly. Please let us know if you think more text is needed.
=====================================================
Consider a contrived three node network where each node accumulates
!!CEP: maybe "contrived --> simple".
[Yingzhen]: changed as suggested.
power through solar panels. Power available for Radio Frequency (RF)
transmission is shown below in Figure 1. In this figure, each of the
three nodes (Node 1, Node 2, and Node 3) have a different plot of
=====================================================
* At time t1 Node 1 and Node 2 have their radios powered and are
!!CEP: maybe "powered on".
expected to communicate.
[Yingzhen]: changed as suggested.
=====================================================
When a node operates using some pre-existing infrastructure there is
(typically) some cost associated with the use of that infrastructure.
!!CEP: parentheses not desirable.
[Yingzhen]: removed the parentheses.
Sample costs include items such as the following.
!!CEP: delete "items such as".
[Yingzhen]: done.
1. Nodes that use existing wireless communications such as a
cellular infrastructure must pay to communicate to and through
=====================================================
over time presumes that the node exists within a defined environment
(or infrastructure). Some necessary characteristics of these
environments are listed as follows.
!!CEP: delete "necessary".
[Yingzhen]: done.
1. Cost Measureability. The impacts of operating a node within its
environment can be measured in a deterministic way. For example,
=====================================================
environment persist for a sufficient amount of time such that
behavior can be adjusted in response to changing costs. If costs
change rapidly or near continuously it is likely not possible to
!!CEP: maybe "change rapidly or near continuously" -- "change too rapidly".
meaningfully react to their change.
[Yingzhen]: changed as suggested.
=====================================================
4. Cost Magnitude. The magnitude of cost changes are such that a
node sees a minimum threshold cost reduction as a result of
optimization.
!!CEP: This is nearly meaningless unless a time-period is specified
over which the cost reduction is measured.
[Yingzhen]: Rewrote the text as the following:
The magnitude of cost changes is such that a node experiences a minimum threshold cost reduction through optimization. A specified time period is designated for measuring the cost reduction.
4.2. Routing Impacts
=====================================================
Consider a contrived three node network, similar to the one pictured
!!CEP: maybe "contrived --> simple".
[Yingzhen]: fixed.
in Figure 1, except that in this case the resource that varies over
time is the cost of the data exchange. This case is illustrated
below in Figure 3. In this figure, a series of three plots are
=====================================================
platform (and thus the mobility of the node) may cause changes to the
topology of the network over time. Since the topology is realized by
(pre)planned actions of the nodes, the impacts on the dynamics of the
!!CEP: delete first clause "Since the topology is realized ...".
[Yingzhen]: done.
topology can be very important. To the extent that the relative
mobility between and among nodes in the network and the impacts of
the environment on the signal propagation can be understood in
advance, the associated loss and establishment of adjacencies can
!!CEP: "understood in advance" --> "predicted".
[Yingzhen]: changed as suggested.
also be planned for.
Mobility can cause the loss of an adjacent link in several ways, such
=====================================================
4. Nodes that can change the orientation of their communication
terminals will also establish and lose connectivity with other
nodes as a function of that motion.
!!CEP: should mention moving behind barriers, and out from behind barriers.
[Yingzhen]: changed the text to:
Nodes equipped with communication terminals capable of adjusting their orientation or moving behind and emerging from barriers will also establish and lose connectivity with other nodes as a function of that motion.
=====================================================
Mobile nodes (like any node) may have concerns related to resource
preservation and cost efficiency, but they can also have concerns
uniquely attributed to their mobility. This on-off availability of
!!CEP: maybe "on-off" --> "intermittent", here and elsewhere.
[Yingzhen]: done.
=====================================================
the links may then induce dynamic pointing mechanisms at the node's
!!CEP: "pointing mechanisms" seems ambiguous; reword.
level. This use case focuses on understanding the routing
implications of motion-related changes to a network topology.
[Yingzhen]: I've rewritten this paragraph:
Mobile nodes, like any node, may have concerns regarding resource preservation and cost efficiency. However, they also face unique challenges associated with their mobility. The intermittent availability of links can lead to dynamic neighbor relationships at the node level. This use case aims to examine the routing implications of motion-induced changes to network topology.
=====================================================
1. Path Predictability. The path of a mobile node through its
environment is known (or can be predicted) as a function of (at
least) time. it is presumed that mobile nodes using time-variant
!!CEP: "it" --> "It".
algorithms would not exhibit purely random motion.
[Yingzhen]: fixed.
=====================================================
5.2. Routing Impacts
Changing a network topology has a straightforward impact on the
!!CEP: "has a straightforward impact on" --> "affects".
computation of paths (or subpaths) through that topology.
[Yingzhen]: changed as suggested.
=====================================================
A LEO-NC represents a good example of planned mobility based on the
predictability of spacecraft in orbit. While other mobile vehicles
might experience unpredictable significant changes to speed,
!!CEP: "speed" --> "velocity".
[Yingzhen]: changed as suggested.
=====================================================
spacecraft operate in a less impactful environment. This determinism
!!CEP: maybe "have very few unpredictable changes to their velocity".
makes them an excellent candidate for time-variant route
[Yingzhen]: Rewrote the text as the following:
While other mobile vehicles may encounter unpredictable fluctuations in velocity, spacecraft operate in an environment with relatively stable velocity conditions.
=====================================================
computations. It is worth pointing out that unplanned inter-
!!CEP: delete "It is worth pointing out that unplanned".
[Yingzhen]: Done.
=====================================================
satellite links failures could still introduce randomness in the
!!CEP: "link" (singular).
!!CEP: "randomness" --> "unpredictability".
network topology.
[Yingzhen]: fixed.
=====================================================
in Figure 6. While these spacecraft are all mobile, their relative
mobility ensures that they are always in contact with each other
(absent any true error condition).
!!CEP: "ensures" is wrong, and the parenthesized phrase needs revision.
What is a "true error"??
[Yingzhen]: Rewrote the sentence as follows:
While these spacecraft are all mobile, their relative mobility ensures continuous contact with each other under normal conditions.
=====================================================
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
