[netconf] Magnus Westerlund's Discuss on draft-ietf-netconf-subscribed-notifications-25: (with DISCUSS and COMMENT)

[Magnus Westerlund via Datatracker <[e-mail]>]

Magnus Westerlund has entered the following ballot position for
draft-ietf-netconf-subscribed-notifications-25: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

My focus when reviewing this document was from a perspective of how to handle
overload. I have a hard time understanding how this will actually work,
especially in a fashion that preservers goodput and ensure what is considered
the most important subscriptions are delivered. Not having good undertanding
into netconf and restconf don't hesitate to call out likely missunderstanding
by me and provide clarification and pointers.

A) The QoS and priority sending mechanism discussed in 2.3 and furhter defined
by the YANG model.

I do want to raise the usage of the DSCP code point to a discuss. As the DSCP
defines different PHB and relative priorities in the router queues a DSCP value
does not provide the publisher any information about priority. I get the
feeling from the text that this may be intended. If the only intention is to
have the transport perform differential treatment in the network between the
publisher and the receiver there are still more considerations are needed.
First of all I think these sentence needs a total rewrite:

   If the publisher supports the "dscp" feature, then a subscription
   with a "dscp" leaf MUST result in a corresponding [RFC2474] DSCP
   marking being placed within the IP header of any resulting
   notification messages and subscription state change notifications.
   Where TCP is used, a publisher which supports the "dscp" feature
   SHOULD ensure that a subscription's notification messages are
   returned within a single TCP transport session where all traffic
   shares the subscription's "dscp" leaf value.

I think one need to put a requriement on the transport to use a transport that
utilize the DSCP marking on its traffic. Which for the current set of
connection oriented transport protocols, TCP, SCTP, and QUIC all currently only
support using a single DSCP per connection. Implying multiple transport
protocol connections using a particular transport to enable this mapping.

A.2 Queuing model of a publisher.
With the DSCP and the Weight and dependency model I think it is important to
clarify the model of the queueing in the publisher. So is the intention that
several subscriptions with different weights and possibly dependencies have
their individual queues that goes into a scheduler? To avoid complex queue
interactions on this level I think there need to be seperate scheduler
instances per DSCP. I would also note that Dependency mechanism can't ensure
that a dependent stream arrive at receiver after the identified dependency if
they are on different DSCP. In fact if one would have HTTP/3 (over QUIC) we may
not even guarantee it within a single connection and same DSCP due to packet
loss impact. To me this model and what relationship one need to consider here
need to be clarified. I think RFC 7540 Section 5.3.1 is an excellent indication
of just the importance of considering what is in the same dependency tree and
what it means to have different weighting. To conclude I think this needs a
model description and clearer definition and possibly requirements towards the
transport. Espceially if you actually need an in-order delivery requirement?

B. The unpredictability of the circuit breaker overload mechanism.

My description of the overload handling in this document is that it is a
circuit breaker based mechanism that can blow a fuse on subscriptions that it
fails to honor in overload situations. What worries me deply is the total
unpredictability of this mechanism.

First, is it the intention to derive what subscriptions are least important
from the DSCP, weighting and Dependency parameters? If it is, I think that may
be a misstake as priority on what subscriptions are most important to retain
are not necessarily reflected in their QoS parameters.

Secondly, what are the values when a subscription are considered to be to heavy
or not be handled accordingly. Are there any parameter sets that actually
describe what SLA the subscriber expect that can be converted into timeout
timers or buffer depth thresholds to indicate that publisher side isn't
delivering these in time?

Third, I what I understand there are no any additional back pressure mechanism
between the receiver and the publisher than the transport protocols flow
control? So a receiver that is not keeping up processing the data it process
will not read out the data out of the flow controlled buffers in the receiver
and thus prevent the publisher to write to the transport conncetion, thus
causing the publisher to eventually trigger a suspension due to its queue build
up?

To my understanding the current mechanism places all subscriptions on the same
importance and with the same SLA. Thus likely causing short term overload
situations to cause subscription suspensions in random subscriptions. Is the WG
fine with this type of randomness occuring and expecting that normally there
will be such amount of overprovisioning that being able to indicate priority
and SLA are overkill?

At a minimal a change of this sentence in Section 2.5.1 is needed:

  This could
   be for reasons of an unexpected but sustained increase in an event
   stream's event records, degraded CPU capacity, a more complex
   referenced filter, or other higher priority subscriptions which have
   usurped resources.

As it states that subscriptions has priorities without reference to a mechanism
that provides that priority.

C. 2.4.5.  Killing a Dynamic Subscription

   The "kill-subscription" operation permits an operator to end a
   dynamic subscription which is not associated with the transport
   session used for the RPC.  A publisher MUST terminate any dynamic
   subscription identified by the "id" parameter in the RPC request, if
   such a subscription exists.

Can someone please clarify the use case for this functionality. To my
understanding it allows another receiver given authority to kill the
subscription being delivered to another receiver. Based on the otherwise rather
strict that all manipulations of dynamic subscriptions happens from the
transport session context that established it I want to better understand the
use case it appears out place.

D. The Requirements on a transport supporting Configured Subscriptions
Reading through Section 2.5 I arrived at a number of questions. I tried to
understand what the requirements are for the transport that supports Configured
Subscriptions. I did note that neither draft-ietf-netconf-restconf-notif-13 nor
draft-ietf-netconf-netconf-event-notifications-17 supports configured
subscriptions. Thus, there appear no template for a solution either, or does
there exist another document that is being worked on defining such a transport?

Questions that arose for me related to Configured Susbription Transport where
the following: 1. Can Transport Session be initiated in both direction. RFC
8071 provides a solution for Publisher to Receiver initiation. It is unclear if
all parts are in place to have a receiver to publisher initiated transport to
be bound to the subscription. 2. What is "name" really? It appears to be
defined as an empty container. Despite that it appears to have requirements on
being both a security identity as well as network address. 3. In Figure 9,
which is stated to be for the receiver. What information does the receiver use
to determine the transition (d)? And what does it do in this step. Related to
Discuss part B). 4. RFC 8071 appears to lack any considerations for how often
and how many times it attempts to connect to the receiver. So applying that
mechanism appears to require some usage guidance to avoid causing overload
situations or DoS potential by misconfiguring network devices with this
soltution to dial out frequently to a target.

As the transport solution requirements are not detail it is actually hard to
determine if there are short comings in the description in Section 2.5 and the
corresponding YANG model. Is it an reasonable request to document these
requirements?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. Section 2.3: DSCP domains
I think the text could benefit from pointing out that the subscriber actually
needs to know what the DSCP values represents in the diffserv domain of the
publisher. As these could be different, they also create an interesting
problems for transports of how they establish a transport connection that uses
a particular DSCP, as the receiver if initiating need to know the local DSCP
value that corresponds to the behavior in the publisher's domain.

2. In general I think there are more than one description that are fuzzy about
if it describes a publisher or receiver action/requirement.