Re: [Dime] Updated DOIC Requirements Analysis

[Maria Cruz Bartolome <[e-mail]>]

Hello,

See some comments below
Thanks
/MCruz

From: DiME [mailto:[e-mail]] On Behalf Of Ben Campbell
Sent: martes, 25 de noviembre de 2014 3:19
To: [e-mail] list
Subject: [Dime] Updated DOIC Requirements Analysis

Here's the text from the updated requirements analysis. I updated the summary to be more general, and updated the detail based on mail discussion. The detail section is marked for deletion before publication as an RFC.

BTW, It's appendix C now because I used the section Steve had already reserved for it :-)

Thanks!

Ben.
-------------------

Appendix C.  Requirements Conformance Analysis



   This section contains the result of an analysis of the DOIC solutions

   conformance to the requirements defined in [RFC7068].



C.1.  Deferred Requirements



   The DIME working group chose to defer certain requirements in order

   to meet an an external deadline.  The 3GPP "Core Network and

   Terminal" working group 4 (CT4) working group wished to reference

   DOIC as part of Release 12.  This required the DOIC base protocol to

   be substantially complete by the end of 2014.  The deferred work

   includes the following:



   o  Agent Overload - The ability for an agent to report an overload

      condition of the agent itself.



   o  Load Information - The ability for a node to report its load level

      when not overloaded.



   At the time of this writing, DIME has begun separate work efforts for

   these requirements.



C.2.  Detection of non-supporting Intermediaries



   The DOIC mechanism as currently defined does not allow supporting

   nodes to automatically determine whether OC-Supported-Features or OC-

   OLR AVPs are originated by a peer node, or by a non-peer node and

   sent across a non-supporting peer.  This makes it impossible to

   detect the presence of non-supporting nodes between supporting nodes,

   except by configuration.  The working group determined that such a

   configuration requirement is acceptable.



   This limits full compliance with certain requirements related to the

   limitation of new configuration, deployment in environments with

   mixed support, operating across non-supporting agents, and

   authorization.

[MCruz] I think this paragraph should state what are the limitations (generally, like you did for rest of them)

Morever, since detailed descriptions will be deleted.



C.3.  Implicit Application Indication



   The working group elected to determine the application for an

   overload report from that of the enclosing message.  This prevents

   sending an OLR for an application when there are no transactions for

   that application.



   As a consequence, DOIC does not comply with the requirement to be

   able to report overload information across quiescent connections.

   DOIC does not fully comply with requirements to operate on up-to-date

   information, since if an OLR causes all transactions to stop for an

   application, the only way traffic will resume is for the OLR to

   expire.



C.4.  Stateless Operation



   RFC7068 explicitly discourages the sending of OLRs in every answer

   message, as part of the requirement to avoid additional work for

   overloaded nodes.  DOIC recommends exactly that behavior during

   active overload conditions.  The working group determined that doing

   otherwise would reduce reliability and increase statefulness.  (Note

   that DOIC does allow nodes to avoid sending OLRs in every answer if

   they have some other method of ensuring that OLRs get to all relevant

   reacting nodes.)



C.5.  No New Vulnerabilities



   The working group believes that DOIC is compliant with the

   requirement to avoid introducing new vulnerabilities.  However, this

   requirement may warrant an early security expert review.



C.6.  Detailed Requirements



   [RFC Editor: Please remove this section and subsections prior to

   publication as an RFC.]



C.6.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 or the ability to report overload of an agent.

           These have been left for future extensions.







   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.



           *Partially Compliant*. The DOIC AVPs can be used in any

           application that allows the extension of AVPs.  However,

           "load" information is not currently supported.







   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.







   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.



[MCruz] Could you clarify last example? "withoug configuration"? I do not understand what you meant.



C.6.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 reporting nodes 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.







C.6.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.







   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.







C.6.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.



[MCruz] Partly Compliant. DOIC Overload information can be used already by proprietary load-balancing implementations.

Load information will be a plus to this.





   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.







C.6.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.







C.6.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.



           *Compliant*. The working group is not aware of any such

           vulnerabilities.  [This may need 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.

[MCruz] Could you point our where in the draft it is described?





C.6.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).  DOIC does not provide a

           way for supporting nodes to detect such modification.