Subject: [Dime] DOIC Requirements Analysis

From: Ben Campbell <[email-masked]>
Date: Tue, 21 Oct 2014 17:10:05 -0500

Hi,
Benoit requested that the DOIC draft include a requirements analysis against the requirements from RFC 7068. I’ve made an attempt that that, below.
I realize not everyone will agree on my analysis, and there is considerable room for discussion. However, given Benoit’s request, I think it’s important to get these in as soon as possible; if not in 04, then soon afterwards (i.e. before WGLC, and preferably before Honolulu.)
I also created a branch called “Reqs-Analysis" in the GitHub repository that contains  these in XML form.
Thanks!
Ben.
----------------------------------------------
Appendix D.  Requirements Analysis

   This section analyzes the mechanism described in this document
   against the set of requirements detailed in [RFC7068].

D.1.  General

   REQ 1:  The solution MUST provide a communication method for Diameter
           nodes to exchange load and overload information.

           *Partially Compliant*. The mechanism uses new AVPs
           piggybacked on existing Diameter messages to exchange
           overload information.  It does not currently support "load"
           information.  Indication of "Load" information has been left
           for a future extension.

   REQ 2:  The solution MUST allow Diameter nodes to support overload
           control regardless of which Diameter applications they
           support.  Diameter clients and agents must be able to use the
           received load and overload information to support graceful
           behavior during an overload condition.  Graceful behavior
           under overload conditions is best described by REQ 3.

           *Compliant*. The DOIC AVPs can be used in any application
           that allows the extension of AVPs.

   REQ 3:  The solution MUST limit the impact of overload on the overall
           useful throughput of a Diameter server, even when the
           incoming load on the network is far in excess of its
           capacity.  The overall useful throughput under load is the
           ultimate measure of the value of a solution.

           *Compliant*. DOIC provides information that nodes can use to
           reduce the impact of overload.

   REQ 4:  Diameter allows requests to be sent from either side of a
           connection, and either side of a connection may have need to
           provide its overload status.  The solution MUST allow each
           side of a connection to independently inform the other of its
           overload status.

           *Compliant*. DOIC AVPs can be included regardless of
           transaction "direction"

   REQ 5:  Diameter allows nodes to determine their peers via dynamic
           discovery or manual configuration.  The solution MUST work
           consistently without regard to how peers are determined.

           *Compliant*. DOIC contains no assumptions about how peers are
           discovered.  [Note: This may require further study]

   REQ 6:  The solution designers SHOULD seek to minimize the amount of
           new configuration required in order to work.  For example, it
           is better to allow peers to advertise or negotiate support
           for the solution, rather than to require that this knowledge
           to be configured at each node.

           *Partially Compliant*. Most DOIC parameters are advertised
           using the DOIC capability announcement mechanism.  However,
           there are some situations where configuration is required.
           For example, a DOIC node detect the fact that a peer may not
           support DOIC when nodes on the other side of the non-
           supporting node do support DOIC without configuration.

D.2.  Performance

   REQ 7:  The solution and any associated default algorithm(s) MUST
           ensure that the system remains stable.  At some point after
           an overload condition has ended, the solution MUST enable
           capacity to stabilize and become equal to what it would be in
           the absence of an overload condition.  Note that this also
           requires that the solution MUST allow nodes to shed load
           without introducing non-converging oscillations during or
           after an overload condition.

           *Compliant*. The specification offers guidance that
           implementations should apply hysteresis when recovering from
           overload, and avoid sudden ramp ups in offered load when
           recovering.

   REQ 8:  Supporting nodes MUST be able to distinguish current overload
           information from stale information.

           *Partially Compliant*. DOIC overload reports are "soft
           state", that is they expire after an indicated period.  DOIC
           nodes may also send reports that end existing overload
           conditions.  DOIC requires reporting nodes to ensure that all
           relevant reacting nodes receive overload reports.

           However, since DOIC does not allow reports to send OLRs in
           watchdog messages, if an overload condition results in zero
           offered load, the reporting node cannot update the condition
           until the expiration of the original OLR.

   REQ 9:  The solution MUST function across fully loaded as well as
           quiescent transport connections.  This is partially derived
           from the requirement for stability in REQ 7.

           *Not Compliant*. DOIC does not allow OLRs to be sent over
           quiescent transport connections.  This is due to the fact
           that OLRs cannot be sent outside of the application to which
           they apply.

   REQ 10: Consumers of overload information MUST be able to determine
           when the overload condition improves or ends.

           *Partially Compliant*. (See response to previous two
           requirements.)

   REQ 11: The solution MUST be able to operate in networks of different
           sizes.

           *Compliant*. DOIC makes no assumptions about the size of the
           network.  DOIC can operate purely between clients and
           servers, or across agents.

   REQ 12: When a single network node fails, goes into overload, or
           suffers from reduced processing capacity, the solution MUST
           make it possible to limit the impact of the affected node on
           other nodes in the network.  This helps to prevent a small-
           scale failure from becoming a widespread outage.

           *Partially Compliant*. DOIC allows overload reports for an
           entire realm, where abated traffic will not be redirected
           towards another server.  But in situations where nodes choose
           to divert traffic to other nodes, DOIC offers no way of
           knowing whether the new recipients can handle the traffic if
           they have not already indicated overload.  This may be
           mitigated with the use of a future "load" extension, or with
           the use of proprietary dynamic load-balancing mechanisms.

   REQ 13: The solution MUST NOT introduce substantial additional work
           for a node in an overloaded state.  For example, a
           requirement for an overloaded node to send overload
           information every time it received a new request would
           introduce substantial work.

           *Not Compliant*. DOIC does in fact encourage an overloaded
           node to send an OLR in every response.  The working group
           that other mechanisms to ensure that every relevant node
           receives an OLR would create even more work.  [Note: This
           needs discussion.]

   REQ 14: Some scenarios that result in overload involve a rapid
           increase of traffic with little time between normal levels
           and levels that induce overload.  The solution SHOULD provide
           for rapid feedback when traffic levels increase.

           *Compliant*. The piggyback mechanism allows OLRs to be sent
           at the same rate as application traffic.

   REQ 15: The solution MUST NOT interfere with the congestion control
           mechanisms of underlying transport protocols.  For example, a
           solution that opened additional TCP connections when the
           network is congested would reduce the effectiveness of the
           underlying congestion control mechanisms.

           *Compliant*. DOIC does not require or recommend changes in
           the handling of transport protocols or connections.

D.3.  Heterogeneous Support for Solution

   REQ 16: The solution is likely to be deployed incrementally.  The
           solution MUST support a mixed environment where some, but not
           all, nodes implement it.

           *Partially Compliant*. DOIC works with most mixed-deployment
           scenarios.  However, it cannot work across a non-supporting
           proxy that modifies Origin-Host AVPs in answer messages.
           DOIC will have limited impact in networks where the nodes
           that perform server selections do not support the mechanism.

   REQ 17: In a mixed environment with nodes that support the solution
           and nodes that do not, the solution MUST NOT result in
           materially less useful throughput during overload as would
           have resulted if the solution were not present.  It SHOULD
           result in less severe overload in this environment.

           *Compliant*. In most mixed-support deployment, DOIC will
           offer at least some value, and will not make things worse.

   REQ 18: In a mixed environment of nodes that support the solution and
           nodes that do not, the solution MUST NOT preclude elements
           that support overload control from treating elements that do
           not support overload control in an equitable fashion relative
           to those that do.  Users and operators of nodes that do not
           support the solution MUST NOT unfairly benefit from the
           solution.  The solution specification SHOULD provide guidance
           to implementors for dealing with elements not supporting
           overload control.

           *Compliant*. DOIC provides mechanisms to abate load from non-
           supporting sources.  Furthermore, it recommends that
           reporting nodes will still need to be able to apply whatever
           protections they would ordinarily apply if DOIC were not in
           use.

   REQ 19: It MUST be possible to use the solution between nodes in
           different realms and in different administrative domains.

           *Partially Compliant*. DOIC allows sending OLRs across
           administrative domains, and potentially to nodes in other
           realms.  However, an OLR cannot indicate overload for realms
           other than the one in the Origin-Realm AVP of the containing
           answer.

   REQ 20: Any explicit overload indication MUST be clearly
           distinguishable from other errors reported via Diameter.

           *Compliant*. DOIC sends explicit overload indication in
           overload reports.  It does not depend on error result codes.
           [Note: I don't think the resuse of too-busy and unable-to-
           comply for throttled requests impacts this requirement.  Do
           others agree?]

   REQ 21: In cases where a network node fails, is so overloaded that it
           cannot process messages, or cannot communicate due to a
           network failure, it may not be able to provide explicit
           indications of the nature of the failure or its levels of
           overload.  The solution MUST result in at least as much
           useful throughput as would have resulted if the solution were
           not in place.

           *Compliant*. DOIC overload reports have the primary effect of
           suppressing message retries in overload conditions.  DOIC
           recommends that messages never be silently dropped if at all
           possible.

D.4.  Granular Control

   REQ 22: The solution MUST provide a way for a node to throttle the
           amount of traffic it receives from a peer node.  This
           throttling SHOULD be graded so that it can be applied
           gradually as offered load increases.  Overload is not a
           binary state; there may be degrees of overload.

           *Compliant*. The "loss" algorithm expresses a percentage
           reduction.

   REQ 23: The solution MUST provide sufficient information to enable a
           load-balancing node to divert messages that are rejected or
           otherwise throttled by an overloaded upstream node to other
           upstream nodes that are the most likely to have sufficient
           capacity to process them.

           *Not Compliant*. DOIC provides no built in mechanism to
           determine the best place to divert messages that would
           otherwise be throttled.  This can be accomplished with a
           future "load" extension, or with proprietary load balancing
           mechanisms.

   REQ 24: The solution MUST provide a mechanism for indicating load
           levels, even when not in an overload condition, to assist
           nodes in making decisions to prevent overload conditions from
           occurring.

           *Not Compliant*. "Load" information has been left for a
           future extension.

D.5.  Priority and Policy

   REQ 25: The base specification for the solution SHOULD offer general
           guidance on which message types might be desirable to send or
           process over others during times of overload, based on
           application-specific considerations.  For example, it may be
           more beneficial to process messages for existing sessions
           ahead of new sessions.  Some networks may have a requirement
           to give priority to requests associated with emergency
           sessions.  Any normative or otherwise detailed definition of
           the relative priorities of message types during an overload
           condition will be the responsibility of the application
           specification.

           *Compliant*. The specification offers guidance on how
           requests might be prioritized for different types of
           applications.

   REQ 26: The solution MUST NOT prevent a node from prioritizing
           requests based on any local policy, so that certain requests
           are given preferential treatment, given additional
           retransmission, not throttled, or processed ahead of others.

           *Compliant*. Nothing in the specification prevents
           application-specific, implementation-specific, or local
           policies.

D.6.  Security

   REQ 27: The solution MUST NOT provide new vulnerabilities to
           malicious attack or increase the severity of any existing
           vulnerabilities.  This includes vulnerabilities to DoS and
           DDoS attacks as well as replay and man-in-the-middle attacks.
           Note that the Diameter base specification [RFC6733] lacks
           end-to-end security and this must be considered (see the
           Security Considerations in [RFC7068]).  Note that this
           requirement was expressed at a high level so as to not
           preclude any particular solution.  Is is expected that the
           solution will address this in more detail.

           *Unknown*. [Needs further analysis.]

   REQ 28: The solution MUST NOT depend on being deployed in
           environments where all Diameter nodes are completely trusted.
           It SHOULD operate as effectively as possible in environments
           where other nodes are malicious; this includes preventing
           malicious nodes from obtaining more than a fair share of
           service.  Note that this does not imply any responsibility on
           the solution to detect, or take countermeasures against,
           malicious nodes.

           *Partially Compliant*. Since all Diameter security is
           currently at the transport layer, nodes must trust immediate
           peers to enforce trust policies.  However, there are
           situations where a DOIC node cannot determine if an immediate
           peer supports DOIC.  The authors recommend an expert security
           review.

   REQ 29: It MUST be possible for a supporting node to make
           authorization decisions about what information will be sent
           to peer nodes based on the identity of those nodes.  This
           allows a domain administrator who considers the load of their
           nodes to be sensitive information to restrict access to that
           information.  Of course, in such cases, there is no
           expectation that the solution itself will help prevent
           overload from that peer node.

           *Partially Compliant*. (See response to previous
           requirement.)

   REQ 30: The solution MUST NOT interfere with any Diameter-compliant
           method that a node may use to protect itself from overload
           from non-supporting nodes or from denial-of-service attacks.

           *Compliant*. The specification recommends that any such
           protection mechanism needed without DOIC should continue to
           be employed with DOIC.

D.7.  Flexibility and Extensibility

   REQ 31: There are multiple situations where a Diameter node may be
           overloaded for some purposes but not others.  For example,
           this can happen to an agent or server that supports multiple
           applications, or when a server depends on multiple external
           resources, some of which may become overloaded while others
           are fully available.  The solution MUST allow Diameter nodes
           to indicate overload with sufficient granularity to allow
           clients to take action based on the overloaded resources
           without unreasonably forcing available capacity to go unused.
           The solution MUST support specification of overload
           information with granularities of at least "Diameter node",
           "realm", and "Diameter application" and MUST allow
           extensibility for others to be added in the future.

           *Partially Compliant*. All DOIC overload reports are scoped
           to the specific application and realm.  Inside that scope,
           overload can be reported at the specific server or whole
           realm scope.  As currently specified, DOIC cannot indicate
           local overload for an agent.  At the time of this writing,
           the DIME working group has plans to work on an agent-overload
           extension.

           DOIC allows new "scopes" through the use of extended report
           types.

   REQ 32: The solution MUST provide a method for extending the
           information communicated and the algorithms used for overload
           control.

           *Compliant*. DOIC allows new report types and abatement
           algorithms to be created.  These may be indicated using the
           OC-Supported-Features AVP.

   REQ 33: The solution MUST provide a default algorithm that is
           mandatory to implement.

           *Compliant*. The "loss" algorithm is mandatory to implement.

   REQ 34: The solution SHOULD provide a method for exchanging overload
           and load information between elements that are connected by
           intermediaries that do not support the solution.

           *Partially Compliant*. DOIC information can traverse non-
           supporting agents, as long as those agents do not modify
           certain AVPs. (e.g., Origin-Host)