Subject: Re: [Dime] Updated DOIC Requirements Analysis

From: Steve Donovan <[email-masked]>
Date: Tue, 02 Dec 2014 12:41:39 -0600

Lionel,

I currently have the following for the Introduction based on other 
suggestions from, I believe, Ben:

    This specification defines a base solution for Diameter overload
    control, referred to as Diameter Overload Indication Conveyance
    (DOIC).  The requirements for the solution are described and
    discussed in the corresponding requirements document [RFC7068].

    This specification addresses Diameter overload control between
    Diameter nodes that support the DOIC solution.  The solution, which
    is designed to apply to existing and future Diameter applications,
    requires no changes to the Diameter base protocol [RFC6733] and is
    deployable in environments where some Diameter nodes do not implement
    the Diameter overload control solution defined in this specification.

    Note that the overload control solution defined in this specification
    does not address all the requirements listed in [RFC7068].  A number
    of overload control related features are left for future
    specifications.  See Appendix A for a list of extensions that are
    currently being considered.  See Appendix C for an analysis of
    conformance to the requirements specified in [RFC7068].

Let me know if this works for you.

I have included your other suggestion below.

Regards,

Steve

On 11/25/14, 1:02 PM, [email-masked] wrote:
> Hi Ben, Steve,
>
> the text in section 1 needs also to be updated. I would propose something like:
>
> 1.  Introduction
>
>     This specification defines a base solution for Diameter Overload
>     Control (DOC), referred to as Diameter Overload Indication Conveyance
>     (DOIC).  The requirements for the solution are described and
>     discussed in the corresponding design requirements document
>     [RFC7068].  Note that the overload control solution defined in this
>     specification does not address all the requirements listed in
>     [RFC7068].  See Appendix C for further details on the
>     conformance to the requirements specified in [RFC7068].
>
> In C.1:
>
> 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:
>
> it is not necessary to quote CT4, as there are other groups impacts. I would propose to rephrase as below:
>
>     3GPP have adopted an early version of this document as normative
>     reference in various Diameter related specifications to support the
>     overload control mechanism in their release 12 framework.  The DIME
>     working group has therefore decided to defer certain requirements in order
>     to complete the design of an extensible generic solution before the
>     deadline scheduled by 3GPP for the completion of the protocol work
>     in release 12 by the end of 2014.  The deferred work includes the following:
>
> regards,
>
> Lionel
>
> De : DiME [mailto:[email-masked]] De la part de Ben Campbell
> Envoyé : mardi 25 novembre 2014 03:19
> À : [email-masked] list
> Objet : [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.
>
> 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.
>
>
>
> 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.
>
>
>
>     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.
>
>
>
> 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.
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: <[email-masked]>
Date: Wed, 3 Dec 2014 10:53:52 +0000

Hi Steve,

For the first paragraph, I would simply say:

   (DOIC), based on the requirements identified in RFC 7068 [RFC7068].

OK for the rest.

Regards,

Lionel

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : mardi 2 décembre 2014 19:42
À : [email-masked]
Objet : Re: [Dime] Updated DOIC Requirements Analysis

Lionel,

I currently have the following for the Introduction based on other suggestions from, I believe, Ben:

Regards,

Steve

On 11/25/14, 1:02 PM, [email-masked]<mailto:[email-masked]> wrote:

Hi Ben, Steve,

1.  Introduction

In C.1:

   includes the following:

regards,

Lionel

À : [email-masked]<mailto:[email-masked]> list

Thanks!

Ben.

-------------------

   includes the following:

      when not overloaded.

   these requirements.

   authorization.

   that application.

   expire.

C.4.  Stateless Operation

   reacting nodes.)

   publication as an RFC.]

C.6.1.  General

           overload status.

           transaction "direction"

           discovered.

C.6.2.  Performance

           recovering.

           they apply.

           requirements.)

           sizes.

           needs discussion.]

           all, nodes implement it.

           overload control.

           use.

           answer.

           not in place.

           possible.

C.6.4.  Granular Control

           reduction.

           mechanisms.

           occurring.

           future extension.

           specification.

           applications.

           policies.

C.6.6.  Security

           malicious nodes.

           review.

           requirement.)

           be employed with DOIC.

           extension.

           types.

           control.

           mandatory to implement.

Thank you.

DiME mailing list

[email-masked]<mailto:[email-masked]>

---

From: Steve Donovan <[email-masked]>
Date: Wed, 03 Dec 2014 11:01:50 -0600

Change made.

On 12/3/14, 4:53 AM, [email-masked] wrote:
> *De :*DiME [mailto:[email-masked]] *De la part de* Steve Donovan
> *Envoyé :* mardi 2 décembre 2014 19:42
> *À :* [email-masked]
> *Objet :* Re: [Dime] Updated DOIC Requirements Analysis
>
> Lionel,
>
>     À :[email-masked]  <mailto:[email-masked]>  list
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Wed, 10 Dec 2014 15:09:16 +0000

Hello,

See some comments below
Thanks
/MCruz

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

Thanks!

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

   includes the following:

      when not overloaded.

   these requirements.

   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.

   that application.

   expire.

C.4.  Stateless Operation

   reacting nodes.)

   publication as an RFC.]

C.6.1.  General

           overload status.

           transaction "direction"

           discovered.

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

C.6.2.  Performance

           recovering.

           they apply.

           requirements.)

           sizes.

           needs discussion.]

           all, nodes implement it.

           overload control.

           use.

           answer.

           not in place.

           possible.

C.6.4.  Granular Control

           reduction.

           mechanisms.

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

Load information will be a plus to this.

           occurring.

           future extension.

           specification.

           applications.

           policies.

C.6.6.  Security

           malicious nodes.

           review.

           requirement.)

           be employed with DOIC.

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

           extension.

           types.

           control.

           mandatory to implement.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Dec 2014 18:08:28 -0600

> On Dec 10, 2014, at 9:09 AM, Maria Cruz Bartolome <[email-masked]> wrote:
> 
> Hello,
>  
> See some comments below
> Thanks
> /MCruz
>  

[...]

> Morever, since detailed descriptions will be deleted.

The limitations are discussed in the security consideration section. Basically if a node expects an agent to enforce any DOIC related policy (e.g. making sure DOIC avps do not leak to unauthorized nodes), it has to know that the agent itself supports DOIC. Right now it can only know that by having an administrator tell it that (violating the limitation on new configuration), by knowing that all agents in the network support DOIC (violating the mixed support and non-supporting agent requirements.)

[...]

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

Here's an example:

C ------ A ------ S

If both C and S support DOIC, there is no way for them to tell whether A supports DOIC. Consider two cases:

1) A supports DOIC. But since C already inserts OC-S-F in all requests, and S inserts it in all answers, A passes them through unchanged.
2) A does not support DOIC, but passes through unknown AVPs. Since OC-S-F will be unknown to it, it passes it through unchanged.

From the perspective of C and S, the requests and answers look identical for both cases. Even if A actually changes the content of an OC-S-F avp, neither endpoint can tell if the resulting AVP came from A or the opposite endpoint.

Personally, I think this is a showstopper. But the working group consensus did not agree.

[...]

> Load information will be a plus to this.

I disagree, or at least think that would be _very_ partial. You won't have any overload information unless the potential diversion targets are also overloaded.

[...]

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

9.3

/Ben.

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Fri, 12 Dec 2014 08:24:17 +0000

Hello Ben,

See comments below
Thanks
/MCruz

> [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.
>  

The limitations are discussed in the security consideration section. Basically if a node expects an agent to enforce any DOIC related policy (e.g. making sure DOIC avps do not leak to unauthorized nodes), it has to know that the agent itself supports DOIC. Right now it can only know that by having an administrator tell it that (violating the limitation on new configuration), by knowing that all agents in the network support DOIC (violating the mixed support and non-supporting agent requirements.)
[MCruz] Please, include text accordingly then. The text now "certain requirements related to" does not provide an information that anyone could trace easily.

Here's an example:

C ------ A ------ S

[MCruz] Several comments:
a) Then you consider this requirement as "partly compliant" since you consider configuration is required in a node to identify whether or not its adjacent peers support DOIC, right? If so, could you explain why a node needs to know whether or not the peer support DOIC, a part from what is included in the advertisement mechanism we defined?
b) What do you think is a "show stopper"? The need for configuration? 

I disagree, or at least think that would be _very_ partial. You won't have any overload information unless the potential diversion targets are also overloaded.
[MCruz] In case servers in the pools are DOIC enabled the Overload information is provided by all of them, under overload occurrences, then this information is valid (maybe not sufficient in all cases, I agree, but valid in most of them) to divert.
In case we have mixed servers (DOIC-supporting and non-DOIC) we have some limitations as well.

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

9.3
[MCruz] I do not think 9.3 says what you mentioned here.
It says "In the absence of an overload control mechanism...". It is not said the DOIC shall not interfere with any other Diameter method for protection, we may need to add this information to the draft in fact.
A part from that, I think 9.3. should say "for non-DOIC supporting nodes/networks..." not just "in the absence of _an_ overload control mechanism"...

/Ben.