Early Review of draft-ietf-rtgwg-net-notif-ps-02
review-ietf-rtgwg-net-notif-ps-02-tsvart-early-scharf-2026-05-22-00

This is a TSVART early review. There request "Please review from transport
perspective and make sure the document doesn't conflict with work in the
transport area." can actually be subdivided into two parts 1/ and /2:

Regarding 1/ "Please review from transport perspective":

The document in its current form is hard to review for quite a number of
reasons, including:

- The document lacks an intuitive use case that would allow to understand the
real-world implications. Figure 1 Looks to me like a generic example for a WAN.

- The document only surveys a subset of existing solutions. Using IETF
protocols, the example shown in figure 1 could be solved e.g. by 1+1 protection
in an optical network (e.g. with GMPLS), or maybe also with IETF DETNET. As the
document also uses the term "switch", it is not clear whether Ethernet
solutions would also be related.

- The document identifies limitations of the analyzed existing solutions, but
it doesn't analyze where these limitations come from, e.g., if there are
reasonable engineering reasons why fast network notifications have not been
done already 10 or 20 years ago. To a transport protocol researcher, quite a
number of RFCs seem related to this question, including RFC 6633 "Deprecation
of ICMP Source Quench Messages", RFC 9805 "Deprecation of the IPv6 Router Alert
Option for New Protocols", RFC 6398 "IP Router Alert Considerations and Usage",
etc. Path-coupled signaling has been standardized in the IETF several times,
e.g., NSIS (see RFC 4080).

One good point is that the document indeed describes a number of challenging
problems, amongst others, security and scalability. But there may be further
challenges. As a background, I recommend having a look at RFC 6077, in
particular section 3.1. Despite its age, at least parts of RFC 6077 are IMHO
still valid and are related to this document.

Some examples for potential further challenges similar to what is explained in
RFC 6077:

1. Partial deployment: In particular when reacting to congestion, a typical
challange are networks in which some routers support a given mechanism, but not
all. One has to analyze whether this can result in wrong decisions. This
problem actually has different aspects, e.g., how to discover whether a
mechanism is actually supported, how to ensure notifications get past routers
that don't support/understand it, how to ensure that there are no interactions
between routers having different knowledge, etc. It is a bit surprising that
none of that is discussed in the document.

2. Information accuracy: The document argues in favor of more fine-grained
information, e.g., regarding congestion status. In section 4.1.2., it even
states "Fast network notification alerts upstream nodes of failure or
congestion in real time". That is not necessarily true. At least for
congestion, it is possible that by the time when a notification reaches an
upstream node, the situation has already changed again and the congestion could
possibly have disappreared again (e.g., for WAN links with a propagation delay
of several milliseconds). I may be wrong, but congestion and link failure
events can have quite different properties. It is suprising that these
different effects are just put into the same category in the document.

3. Interactions with end-to-end congestion control and queue management: More
on that below in 2/.

4. Congestion control of the fast network notifications themselves: While the
document does not use the term "congestion control", it actually explains in
other words that fast network notifications will probably need a congestion
control solution themselves. Strictly speaking, the specific communication
pattern of fast network notifications may actually require a variant of
"reverse path congestion Control", which can easily get non-trivial (e.g., in
partial deployment cases). Solving this could, for instance, imply that the
fast network notifications themselves have to be sent over TCP, QUIC, or some
other sophisticated protocol. And there could be follow-up challenges resulting
from that, including the question whether the foreseen delay targets for fast
network notifications can actually be achieved in combination with a
congestion-controlled transport of the notifications.

Regarding 2/ "make sure the document doesn't conflict with work in the
transport area.":

Conflicts could emerge in different areas. Actually, it is not necessarily the
content of a problem statement document that could cause conflicts. More
important is to ensure that there will be no conflicts when solutions try to
address the problems defined in the document.

This risk could be reduced by adding a number of warning signs to the document:

* End-to-end congestion control is owned in the IETF in WGs of the former IETF
transport area (now WIT), e.g., CCWG, TCPM, TSVWG, QUIC, as well as IRTF ICCRG.
The document should clearly spell out that congestion control algorithms in
endpoints are not in scope. This actually does not only apply to this document,
but e.g. on further related documents, such as a WG charter.

* There are further parts of the the Internet congestion control eco-system
that are also standarized in WGs of the former IETF transport area. Related to
this document could e.g. be queue management algorithms (RED, CoDel, ...), as
well as components of a DiffServ architecture. From the current document, it is
not possible to know whether a fast network notification mechanism could
interact with queue management mechanisms, or whether it would e.g. depend on
internals of a buffer management scheme. For instance, if the fast notification
scheme would disseminate internal state parameters of an AQM scheme, this would
probably overlap with transport area. The document could better explain how
fast network notifications relate to queue management.

* Scalable congestion-controlled fast network notifications may require some
transport protocol for the notifications themselves. How to build such
protocols is a core expertise of the transport area, and it is hard to get this
right. The document could emphasize the value of reusing existing protocols
instead of trying to re-invent the wheel.

These comments are mostly about cross-area collaboration in the IETF, i.e.,
just the standardization process.

But there is also a technical risk when it comes to real-world deployments of
fast network notifications:

Unless care is taken, actions triggered by fast network notifications could
interact in a suboptimal way with end-to-end congestion controls e.g. in TCP or
QUIC. This would be a typical cross-layer interaction. This has been repeatedly
a non-trivial problem in the transport area in the last decades.

Therefore, I explain this cross-layer interaction challenge further - at the
risk of describing something that is obvious to all.

Regarding the given document, the problem is the lack of precise definition of
time-scales, i.e., how "fast" notifications actually will be. It really depends
on time-scales of resource management decisions whether there are cross-layer
interactions between mechanisms inside the network (e.g., in switches or
routers) and end-to-end congestion control (e.g., in TCP or QUIC), or not. And
this time-scale can actually be quantified:

If the document as well as fast network notification solutions ensure that an
reaction to fast network notification becomes active in a time scale
significantly smaller than the smallest RTT of a flow that is affected by that
action, that will most likely happen so fast that it does not interfere with
end-to-end congestion congestion control. It is important to emphasize that not
the absolute time (in sub-milliseconds or milliseconds) matters, as stated in
the document. What actually matters in congestion control is how it relates to
the smallest possible RTT on corresponding links.

A rule-of-thumb for "significantly smaller than the RTT" might be "one order of
magnitude smaller than the smallest RTT of a flow on that link". For instance,
if inside a datacenter the minimum RTT is 0.5 milliseconds, any in-network
actions that change path characteristics faster than 0.05 milliseconds are so
fast that they probably won't conflict with congestion control in endpoints.
Note that this time budget includes both the network notifications *as well as*
actions triggered by them. As another example, if the minimum RTT of flows
traversing a given link is higher, e.g., 10 ms because of use of a WAN, then
the time budget for fast network notifications *and* actions is higher, say, in
total 1 ms. For the latter example, the "millisecond/sub-ms" time scale
mentioned in the document would likely be "fast" enough. For the former, the
situation is less clear.

This example hopefully explains that there could be use cases that require
"sub-0.1ms" time scale for being "fast". Compared to that, the lower boundary
of time scales currently mentioned in the document seems a bit large.

And, specifically, the document lacks an explanation that the relevant baseline
is the _smallest_ RTT of all traffic. This is in particular relevant if RTTs
are different (i.e., mix of both DC-internal and DC-external traffic).

Finally, if fast network notifications (or actually actions triggered by them)
end up in being too slow, i.e., if they operate on a time-scale like the
smallest RTT of flows on a link, it is extremely likely that there will be bad
interactions between such mechanisms inside the network and end-to-end
congestion control, e.g., by TCP or QUIC. The fundamental challenge is that
then several control loops act on the same time-scale (i.e., the RTT). They
will very likely interfere no matter how clever they are engineered, i.e.,
there could be sub-optimal performance, oscillations, and the like.

20+ years of transport protocol and congestion control research is full of
examples for such interactions between congestion control and in-network
resource management mechanisms, including other mechnanisms that react
relatively fast to changes inside the network. Here are some examples:

- Interactions between TCP congestion control and ATM ABR

- Interactions between TCP congestion control and Ethernet flow control

- Interactions between TCP congestion Control and dymamic resource management
in mobile networks (2G, 3G, 4G, 5G)

I believe that the risk of running into similar problems is real, unless, of
course, the network-internal mechanisms are indeed "fast enough".

Regarding this last point, the document should probably have a dedicated
section that explains how relevant it is to avoid interactions with end-to-end
congestion control.

Best regards

Michael