From nobody Tue Dec 2 10:43:04 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75E01A6FC9 for ; Tue, 2 Dec 2014 10:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.779 X-Spam-Level: X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWO8wetlOPaf for ; Tue, 2 Dec 2014 10:42:50 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10BD01A6FC8 for ; Tue, 2 Dec 2014 10:41:46 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63043 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XvsOJ-0009cf-LO for dime@ietf.org; Tue, 02 Dec 2014 10:41:44 -0800 Message-ID: <547E07E3.7090200@usdonovans.com> Date: Tue, 02 Dec 2014 12:41:39 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <46C8B155-A8B0-41F6-A8A5-6F21D61ADE9E@nostrum.com> <16959_1416942163_5474D253_16959_819_1_6B7134B31289DC4FAF731D844122B36E941941@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <16959_1416942163_5474D253_16959_819_1_6B7134B31289DC4FAF731D844122B36E941941@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------040308090400040805030209" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2H3NBO47JgXJRqw3B931cIzm7HM Subject: Re: [Dime] Updated DOIC Requirements Analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 18:42:59 -0000 This is a multi-part message in MIME format. --------------040308090400040805030209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, lionel.morand@orange.com 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:dime-bounces@ietf.org] De la part de Ben Campbell > Envoyé : mardi 25 novembre 2014 03:19 > À : dime@ietf.org 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 > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --------------040308090400040805030209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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, lionel.morand@orange.com 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:dime-bounces@ietf.org] De la part de Ben Campbell
Envoyé : mardi 25 novembre 2014 03:19
À : dime@ietf.org 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
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

--------------040308090400040805030209-- From nobody Tue Dec 2 10:49:47 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5D91A6FC9 for ; Tue, 2 Dec 2014 10:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BZa9g69k_fZ for ; Tue, 2 Dec 2014 10:49:41 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DB051A1EF6 for ; Tue, 2 Dec 2014 10:49:41 -0800 (PST) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63073 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XvsW0-00083A-6D; Tue, 02 Dec 2014 10:49:40 -0800 Message-ID: <547E09C0.5080305@usdonovans.com> Date: Tue, 02 Dec 2014 12:49:36 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, Ben Campbell References: <545792B6.8030502@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, > <087A34937E64E74E848732CFF8354B9209863A54@ESESSMB101.ericsson.se> <24987_1416213505_5469B401_24987_4151_1_judb1lo2cnj5m4v6mdt5aec1.1416213483721@email.android.com> <54748CEA.3020705@usdonovans.com> <19072_1416939968_5474C9C0_19072_1519_1_6B7134B31289DC4FAF731D844122B36E941639@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <19072_1416939968_5474C9C0_19072_1519_1_6B7134B31289DC4FAF731D844122B36E941639@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------070508030007080406070803" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2F-AiHQJ6lWobF7BeQ9cnD2FZvg Cc: "dime@ietf.org" Subject: Re: [Dime] Updates to DOIC -05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 18:49:44 -0000 This is a multi-part message in MIME format. --------------070508030007080406070803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Lionel, The two paragraphs together now say the following: When a reporting node sends an OLR, it effectively delegates any necessary throttling to downstream nodes. If the reporting node also locally throttles the same set of messages, the overall number of throttled request may be higher than intended. Therefore, if a reporting node needs to apply local throttling on a set of messages that match or overlap with existing OCS entries, it needs to consider the impact of throttling by downstream nodes. However, when the reporting node sends an OLR downstream, it might still need to apply other abatement methods such as diversion. The reporting node might also need to throttle requests for reasons other than overload. For example, an agent or server might have a configured rate limit for each client, and throttle requests that exceed that limit, even if such requests had already been candidates for throttling by downstream nodes. Do you see the need for further clarification? Steve On 11/25/14, 12:26 PM, lionel.morand@orange.com wrote: > I'm OK with the idea of the text proposed by Ben. > I would just make clear that throttling is applicable to the fact of sending/forwarding requests (cf. definition). A reporting node may apply local throttling if it is an agent. But if it is a server, it can either drop the exceeded number of requests (no response sent to the downstream) or send a specific DIAMETER-TOO-BUSY response. I think that this clarification is somehow missing in the document. > > Regards, > > Lionel > > -----Message d'origine----- > De : Steve Donovan [mailto:srdonovan@usdonovans.com] > Envoyé : mardi 25 novembre 2014 15:07 > À : Ben Campbell; MORAND Lionel IMT/OLN > Cc : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; Maria Cruz Bartolome > Objet : Re: [Dime] Updates to DOIC -05 > > I'm ok with Ben's wording and will make the change unless I hear objections on the list. > > Steve > > On 11/21/14, 5:01 PM, Ben Campbell wrote: >> On reflection, I think there might be a subtlety here. The resulting offered-load may still exceed the reporting node's current capacity. This can be true even if it's sent an OLR (and thus has related OCS). As mentioned in the surrounding node needs to still be able to protect itself, possibly by throttling. Therefore, I propose the sentence take the form of non-normative guidance. For example: >> >> "When a reporting node sends an OLR, it effectively delegates any necessary throttling to downstream nodes. If the reporting node also locally throttles the same set of messages, the overall number of throttled request may be higher than intended. Therefore, if a reporting node needs to apply local throttling on a set of messages that match or overlap with existing OCS entries, it needs to consider the impact of throttling by downstream nodes." >> >> >>> On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com wrote: >>> >>> I can live with the text proposed by Ulrich. But what is wrong with: >>> >>> " Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which an active OCS applies." ? >>> >>> Envoyé depuis mon Sony Xperia SP d'Orange >>> >>> ---- Maria Cruz Bartolome a écrit ---- >>> >>> >>>> Section 4.2.3, 13th paragraph, 2nd sentence: >>>> Existing text: Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the OLR applies. >>>> Proposed text: Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the sent OLR applies. >>>> >>>> [LM] I would say that the reporting node will not remember the previously sent OLR, but will take care that there is an active OCS. >>> SRD> I'm ok with Ulrich's change. >>> >>> [LM] and this is incorrect but not fundamental. The reporting node does not have to "remember" a previously sent OLR. What it will do is to refer to existing OCS to know that throttling should not be applied. An OCS is a consequence of an sent OLR but it is not an OLR itself. But not fundamental here. >>> >>> [MCruz] I am ok with Ulrich's change. It does not mean that the reporting node needs to "remember" a previously sent OLR, though. The change only proposes to "identify" which OLR we refer to. >>> >>> Best regards >>> /MCruz >>> >>> >>> _____________________________________________________________________ >>> ____________________________________________________ >>> >>> 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 >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________________________________________________________ > > 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. > > --------------070508030007080406070803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lionel,

The two paragraphs together now say the following:

   When a reporting node sends an OLR, it effectively delegates any
   necessary throttling to downstream nodes.  If the reporting node also
   locally throttles the same set of messages, the overall number of
   throttled request may be higher than intended.  Therefore, if a
   reporting node needs to apply local throttling on a set of messages
   that match or overlap with existing OCS entries, it needs to consider
   the impact of throttling by downstream nodes.

   However, when the reporting node sends an OLR downstream, it might
   still need to apply other abatement methods such as diversion.  The
   reporting node might also need to throttle requests for reasons other
   than overload.  For example, an agent or server might have a
   configured rate limit for each client, and throttle requests that
   exceed that limit, even if such requests had already been candidates
   for throttling by downstream nodes.
Do you see the need for further clarification?

Steve


On 11/25/14, 12:26 PM, lionel.morand@orange.com wrote:
I'm OK with the idea of the text proposed by Ben.
I would just make clear that throttling is applicable to the fact of sending/forwarding requests (cf. definition). A reporting node may apply local throttling if it is an agent. But if it is a server, it can either drop the exceeded number of requests (no response sent to the downstream) or send a specific DIAMETER-TOO-BUSY response. I think that this clarification is somehow missing in the document.

Regards,

Lionel

-----Message d'origine-----
De : Steve Donovan [mailto:srdonovan@usdonovans.com] 
Envoyé : mardi 25 novembre 2014 15:07
À : Ben Campbell; MORAND Lionel IMT/OLN
Cc : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; Maria Cruz Bartolome
Objet : Re: [Dime] Updates to DOIC -05

I'm ok with Ben's wording and will make the change unless I hear objections on the list.

Steve

On 11/21/14, 5:01 PM, Ben Campbell wrote:

On reflection, I think there might be a subtlety here. The resulting offered-load may still exceed the reporting node's current capacity. This can be true even if it's sent an OLR (and thus has related OCS). As mentioned in the surrounding node needs to still be able to protect itself, possibly by throttling. Therefore, I propose the sentence take the form of non-normative guidance. For example:

"When a reporting node sends an OLR, it effectively delegates any necessary throttling to downstream nodes.  If the reporting node also locally throttles the same set of messages, the overall number of throttled request may be higher than intended. Therefore, if a reporting node needs to apply local throttling on a set of messages that match or overlap with existing OCS entries, it needs to consider the impact of throttling by downstream nodes."

  

On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com wrote:

I can live with the text proposed by Ulrich. But what is wrong with:

" Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which an active OCS applies." ?

Envoyé depuis mon Sony Xperia SP d'Orange

---- Maria Cruz Bartolome a écrit ----



Section 4.2.3, 13th paragraph, 2nd sentence:
Existing text: Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the OLR applies.
Proposed text: Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the sent OLR applies.

[LM] I would say that the reporting node will not remember the previously sent OLR, but will take care that there is an active OCS.

SRD> I'm ok with Ulrich's change.

[LM] and this is incorrect but not fundamental. The reporting node does not have to "remember" a previously sent OLR. What it will do is to refer to existing OCS to know that throttling should not be applied. An OCS is a consequence of an sent OLR but it is not an OLR itself. But not fundamental here.

[MCruz] I am ok with Ulrich's change. It does not mean that the reporting node needs to "remember" a previously sent OLR, though. The change only proposes to "identify" which OLR we refer to.

Best regards
/MCruz


_____________________________________________________________________
____________________________________________________

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
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


      

      

_________________________________________________________________________________________________________________________

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.




    

    

  


--------------070508030007080406070803--


From nobody Wed Dec  3 01:47:59 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE231A037E for ; Wed,  3 Dec 2014 01:47:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kg3X7ndA_GYU for ; Wed,  3 Dec 2014 01:47:55 -0800 (PST)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61A161A033A for ; Wed,  3 Dec 2014 01:47:54 -0800 (PST)
Received: by mail-lb0-f174.google.com with SMTP id w7so12174605lbi.33 for ; Wed, 03 Dec 2014 01:47:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5Rb7aPrkvbBptdhztcE7gol7UKD5TEp1v2FQ6NKHCvM=; b=DuugYtFixbj7i3uzl4DCLOKNWc2IeXZdOCW+rjCDVZWJlGbX9iL5JkKxlndCr/8xjT XK5myIl8agfbty2WEt9zEVnVpb4eypZSHrPRGuaRJ1BtGPFwhsuoZT9y/AGb2UMII132 IaecWU/2bAc533HQVQhVqHdb2IWFeNwBZ+k6lZ4ww9wH7IER8Sd7znBG9BMArHsZtsSL dTu+cpJbI4SkrRW1xLbDOsM3VPvB7Rs2zEeYCO2HLtgY3cwvuCWNjeBFOmRSGybvt+tc brpAkvtteeqifUqyRFaRGeKQVLF6Z33X1fPXJBP4Kkwnzre5xAM8O8SfODcFkZWh0spO bzrQ==
X-Received: by 10.112.129.228 with SMTP id nz4mr1251890lbb.8.1417600072666; Wed, 03 Dec 2014 01:47:52 -0800 (PST)
Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPSA id vr7sm6309174lbb.21.2014.12.03.01.47.50 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 01:47:51 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Jouni 
In-Reply-To: <547E09C0.5080305@usdonovans.com>
Date: Wed, 3 Dec 2014 11:47:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <010C55AB-73CF-4462-A157-87107644C230@gmail.com>
References: <545792B6.8030502@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, > <087A34937E64E74E848732CFF8354B9209863A54@ESESSMB101.ericsson.se> <24987_1416213505_5469B401_24987_4151_1_judb1lo2cnj5m4v6mdt5aec1.1416213483721@email.android.com>  <54748CEA.3020705@usdonovans.com> <19072_1416939968_5474C9C0_19072_1519_1_6B7134B31289DC4FAF731D844122B36E941639@PEXCVZYM13.corporate.adroot.infra.ftgroup> <547E09C0.5080305@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qREnfkTUmxXz86UNTql7fvuIA_k
Cc: Ben Campbell , "dime@ietf.org" 
Subject: Re: [Dime] Updates to DOIC -05
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Dec 2014 09:47:57 -0000

I would be OK with this text.

- Jouni


> On 02 Dec 2014, at 20:49, Steve Donovan  =
wrote:
>=20
> Lionel,
>=20
> The two paragraphs together now say the following:
>=20
>    When a reporting node sends an OLR, it effectively delegates any
>    necessary throttling to downstream nodes.  If the reporting node =
also
>    locally throttles the same set of messages, the overall number of
>    throttled request may be higher than intended.  Therefore, if a
>    reporting node needs to apply local throttling on a set of messages
>    that match or overlap with existing OCS entries, it needs to =
consider
>    the impact of throttling by downstream nodes.
>=20
>    However, when the reporting node sends an OLR downstream, it might
>    still need to apply other abatement methods such as diversion.  The
>    reporting node might also need to throttle requests for reasons =
other
>    than overload.  For example, an agent or server might have a
>    configured rate limit for each client, and throttle requests that
>    exceed that limit, even if such requests had already been =
candidates
>    for throttling by downstream nodes.
>=20
> Do you see the need for further clarification?
>=20
> Steve
>=20
>=20
> On 11/25/14, 12:26 PM, lionel.morand@orange.com wrote:
>> I'm OK with the idea of the text proposed by Ben.
>> I would just make clear that throttling is applicable to the fact of =
sending/forwarding requests (cf. definition). A reporting node may apply =
local throttling if it is an agent. But if it is a server, it can either =
drop the exceeded number of requests (no response sent to the =
downstream) or send a specific DIAMETER-TOO-BUSY response. I think that =
this clarification is somehow missing in the document.
>>=20
>> Regards,
>>=20
>> Lionel
>>=20
>> -----Message d'origine-----
>> De : Steve Donovan [
>> mailto:srdonovan@usdonovans.com
>> ]=20
>> Envoy=E9 : mardi 25 novembre 2014 15:07
>> =C0 : Ben Campbell; MORAND Lionel IMT/OLN
>> Cc : Wiehe, Ulrich (NSN - DE/Munich);=20
>> dime@ietf.org
>> ; Maria Cruz Bartolome
>> Objet : Re: [Dime] Updates to DOIC -05
>>=20
>> I'm ok with Ben's wording and will make the change unless I hear =
objections on the list.
>>=20
>> Steve
>>=20
>> On 11/21/14, 5:01 PM, Ben Campbell wrote:
>>=20
>>> On reflection, I think there might be a subtlety here. The resulting =
offered-load may still exceed the reporting node's current capacity. =
This can be true even if it's sent an OLR (and thus has related OCS). As =
mentioned in the surrounding node needs to still be able to protect =
itself, possibly by throttling. Therefore, I propose the sentence take =
the form of non-normative guidance. For example:
>>>=20
>>> "When a reporting node sends an OLR, it effectively delegates any =
necessary throttling to downstream nodes.  If the reporting node also =
locally throttles the same set of messages, the overall number of =
throttled request may be higher than intended. Therefore, if a reporting =
node needs to apply local throttling on a set of messages that match or =
overlap with existing OCS entries, it needs to consider the impact of =
throttling by downstream nodes."
>>>=20
>>>  =20
>>>=20
>>>> On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com
>>>>  wrote:
>>>>=20
>>>> I can live with the text proposed by Ulrich. But what is wrong =
with:
>>>>=20
>>>> " Therefore, the reporting node SHOULD NOT apply throttling to the =
set of messages to which an active OCS applies." ?
>>>>=20
>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange
>>>>=20
>>>> ---- Maria Cruz Bartolome a =E9crit ----
>>>>=20
>>>>=20
>>>>=20
>>>>> Section 4.2.3, 13th paragraph, 2nd sentence:
>>>>> Existing text: Therefore, the reporting node SHOULD NOT apply =
throttling to the set of messages to which the OLR applies.
>>>>> Proposed text: Therefore, the reporting node SHOULD NOT apply =
throttling to the set of messages to which the sent OLR applies.
>>>>>=20
>>>>> [LM] I would say that the reporting node will not remember the =
previously sent OLR, but will take care that there is an active OCS.
>>>>>=20
>>>> SRD> I'm ok with Ulrich's change.
>>>>=20
>>>> [LM] and this is incorrect but not fundamental. The reporting node =
does not have to "remember" a previously sent OLR. What it will do is to =
refer to existing OCS to know that throttling should not be applied. An =
OCS is a consequence of an sent OLR but it is not an OLR itself. But not =
fundamental here.
>>>>=20
>>>> [MCruz] I am ok with Ulrich's change. It does not mean that the =
reporting node needs to "remember" a previously sent OLR, though. The =
change only proposes to "identify" which OLR we refer to.
>>>>=20
>>>> Best regards
>>>> /MCruz
>>>>=20
>>>>=20
>>>> =
_____________________________________________________________________
>>>> ____________________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations=20=

>>>> confidentielles ou privilegiees et ne doivent donc pas etre =
diffuses,=20
>>>> exploites ou copies sans autorisation. Si vous avez recu ce message=20=

>>>> 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.
>>>>=20
>>>> This message and its attachments may contain confidential or=20
>>>> 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.
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>> =
__________________________________________________________________________=
_______________________________________________
>>=20
>> 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.
>>=20
>> 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.
>>=20
>>=20
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Dec  3 02:04:42 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BF01A1AB6 for ; Wed,  3 Dec 2014 02:04:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oz9ajzEGsXbf for ; Wed,  3 Dec 2014 02:04:38 -0800 (PST)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1951A0389 for ; Wed,  3 Dec 2014 02:04:19 -0800 (PST)
Received: by mail-la0-f44.google.com with SMTP id ge10so12190919lab.31 for ; Wed, 03 Dec 2014 02:04:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=aoV3dHNy980AuE1O05IJttLoNFmwh9kKoWdT9EcvSK0=; b=K71jp0Sdlc8mBhjgOQum3MKFdC1EUsAujALI8FDJ/i0wgtNxPrM1fCf3dX5Q6uvqxz IASHD4nleOoml/tXdb2AJF/4xK9XcBis01DLT3If1Evy4lnec2/6ibgWixhLqSVRvByu S+nx4a1uWp/fmvescj96pFkY2fllnlGlkNi3Cdem2AWiLmIlZnJs4CpPfCC7RZGHlSr6 ewYC8Sxo3pGMyPgH3heJyM7FaQ00L3NKj4PplSNdOh7gJC3SrvkgJGaGgSWshqNCjHkG 9lf85nO81NZXPmHkRZGxZNO9Out+jiYvh/bK299D/nZcSz9MvCzTHWchmw/fqdfGzrUT sSBA==
X-Received: by 10.152.28.131 with SMTP id b3mr3684746lah.12.1417601058387; Wed, 03 Dec 2014 02:04:18 -0800 (PST)
Received: from ?IPv6:2001:1bc8:101:f101:38c3:cb41:84a2:f0d0? ([2001:1bc8:101:f101:38c3:cb41:84a2:f0d0]) by mx.google.com with ESMTPSA id v7sm4006580lbb.2.2014.12.03.02.04.16 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 02:04:17 -0800 (PST)
From: Jouni 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 3 Dec 2014 12:04:15 +0200
Message-Id: <4A9D369D-E22C-4E21-A887-C9123C23D017@gmail.com>
To: "dime@ietf.org list" 
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/cRVGhnKxfryaQ0ZVmbDPNlow4VY
Subject: [Dime] DIME and adding "load information" to the charter milestones
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Dec 2014 10:04:40 -0000

Folks,

As we discussed in Honolulu there is interest to add a new milestone for =
the load information. Recap from the meeting minutes:

  Ben - we have a path forward for now. Not working group adoption. We =
don't
        have a milestone for load. Although it's implied with solving =
RFC7068
         =20
  Jouni - Who supports adding load to milestones? (7 hands) Against? (0
          hands).
         =20
  ACTION: Ask the mailing list about adding load to the milestones.

So, we are going to add the following milestones (subject to editing) =
unless
enough people express their disagreement by 11th Dec EOB (CET+1):

Mar 2015 - Submit a document on 'Diameter Load Information' as a working =
group item
Mar 2016 - Submit I-D 'Diameter Load Information' to the IESG for =
consideration as a Proposed Standard


- Jouni & Lionel=


From nobody Wed Dec  3 02:12:13 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342281A01FA for ; Wed,  3 Dec 2014 02:12:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkbxj3R16O76 for ; Wed,  3 Dec 2014 02:12:09 -0800 (PST)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 776471A0461 for ; Wed,  3 Dec 2014 02:12:09 -0800 (PST)
Received: by mail-la0-f46.google.com with SMTP id q1so7431079lam.33 for ; Wed, 03 Dec 2014 02:12:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=+sqbpNX1xnVwhga18JCrtX8zUwjL/TVm7PBet8sP/Z8=; b=qtS0u9dSDEKzinntG7PtyAKn6k/71Lh+9MxPVQf0ZrtpNeTIalraYoHzL7xgvxBZPr ysV6Xari6W8M/L30eOE+UxWcgHZu9j7zthwL0PdQBzl11SST9Ci72JHrhzpxij8Z7sww UajTxWzvqut5em5XRywieTpM/8mMRv1y+cyBrRwpeyfd7/vwpmR+IBA3weQG+aX+1Mcl fcEBstgT58pJhXVfKMDIlKPO6dXzgfVO3WUGihl5rxjklZ2S2Wsdkd8UK0+6U414pPgP JRzgFz354MFTcCu+nJaOeiAUZBqX6f5OwEPMhCKmIVkyvN3vm7+2S3WLQmPwPOWKg6tS ItrA==
X-Received: by 10.152.8.82 with SMTP id p18mr3543123laa.25.1417601527998; Wed, 03 Dec 2014 02:12:07 -0800 (PST)
Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPSA id b4sm6326927lbp.17.2014.12.03.02.12.06 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 02:12:07 -0800 (PST)
From: Jouni 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 3 Dec 2014 12:12:05 +0200
Message-Id: 
To: "dime@ietf.org list" 
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/_6_9LDolrrxpDpjFcivU01RJh8g
Subject: [Dime] Call for WG adoption: draft-donovan-dime-doc-rate-control
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Dec 2014 10:12:11 -0000

Folks,

As we discussed and agreed during the Honolulu meeting we ask for the WG =
adoption for draft-donovan-dime-doc-rate-control unless counter =
proposals show up. The "wait period" for counter proposals has been more =
than enough.

This mail starts a two week adoption call for =
draft-donovan-dime-doc-rate-control as a WG Item.

Express your support or disagreements in the mailing list. The call ends=20=

17th Dec EOB (CET+1).

- Jouni & Lionel


From nobody Wed Dec  3 02:12:20 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0F31A0461 for ; Wed,  3 Dec 2014 02:12:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8rbEve6plsL for ; Wed,  3 Dec 2014 02:12:18 -0800 (PST)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18BFD1A01FA for ; Wed,  3 Dec 2014 02:12:16 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id u10so12064002lbd.3 for ; Wed, 03 Dec 2014 02:12:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=9Rh24RICEERPp04UAkMkdwdyQ9frJTcs4lO7cSMvQKI=; b=XoR51mWuh3Eu1eVQuXWsUXtos9lUB0FBa5VujRvhjG1B/Dgz6SgkpD16ihmJ8ljI+V sVbrk3ca7un7Jdjh/UXDT8uqDU7RTrLxkwvkZdeQLgFsEnaOqLgxuDUmZHUFdF79ETHi etZx6ZJASf1IGIFKoDbxSJ2cpVichnvt1GBxNunpCsdSwBZg7cRGXV/I9yfLT01hjzkF id6kthEFnnrr18rcpfSlsfWbpei0a6+ZfPliiouG9PCIFeqHil9nd67gTZ6j+Vz+xAGG V7qBJFKcD1CG1u/pHGnEqXJHvd5s0G8imt6PPATCs6pr3HI/1FOObT8zeCK4LOYkaxHr QsPw==
X-Received: by 10.152.207.37 with SMTP id lt5mr3499847lac.66.1417601534622; Wed, 03 Dec 2014 02:12:14 -0800 (PST)
Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPSA id b4sm6326927lbp.17.2014.12.03.02.12.12 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 02:12:13 -0800 (PST)
From: Jouni 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 3 Dec 2014 12:12:07 +0200
Message-Id: <32615952-7107-45B6-85AD-AD9F57FBE418@gmail.com>
To: "dime@ietf.org list" 
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-c0QZYuetAWaOZNTfEWJuaJX29w
Subject: [Dime] Call for WG adoption: draft-donovan-dime-agent-overload
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Dec 2014 10:12:19 -0000

Folks,

As we discussed and agreed during the Honolulu meeting we ask for the WG =
adoption for draft-donovan-dime-agent-overload unless counter proposals =
show up. The "wait period" for counter proposals has been more than =
enough.

This mail starts a two week adoption call for =
draft-donovan-dime-agent-overload as a WG Item.

Express your support or disagreements in the mailing list. The call ends
17th Dec EOB (CET+1).

- Jouni & Lionel


From nobody Wed Dec  3 02:25:25 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1044D1A0AF7 for ; Wed,  3 Dec 2014 02:25:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level: 
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBSR6dgkhe-N for ; Wed,  3 Dec 2014 02:25:18 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 384F31A1A30 for ; Wed,  3 Dec 2014 02:25:06 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 7ECF02DC194; Wed,  3 Dec 2014 11:25:04 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 6016327C079; Wed,  3 Dec 2014 11:25:04 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 11:25:04 +0100
From: 
To: Jouni , Steve Donovan 
Thread-Topic: [Dime] Updates to DOIC -05
Thread-Index: AQHQDmC9B2lc+qnTi0KtXgvGw5tH5Jx9juCAgAAVEvA=
Date: Wed, 3 Dec 2014 10:25:03 +0000
Message-ID: <12859_1417602304_547EE500_12859_6241_1_6B7134B31289DC4FAF731D844122B36E99A14C@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <545792B6.8030502@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, > <087A34937E64E74E848732CFF8354B9209863A54@ESESSMB101.ericsson.se> <24987_1416213505_5469B401_24987_4151_1_judb1lo2cnj5m4v6mdt5aec1.1416213483721@email.android.com>  <54748CEA.3020705@usdonovans.com> <19072_1416939968_5474C9C0_19072_1519_1_6B7134B31289DC4FAF731D844122B36E941639@PEXCVZYM13.corporate.adroot.infra.ftgroup> <547E09C0.5080305@usdonovans.com> <010C55AB-73CF-4462-A157-87107644C230@gmail.com>
In-Reply-To: <010C55AB-73CF-4462-A157-87107644C230@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.2]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.3.40922
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-a3CCFUmhes9QMOTE_zZ0e611oU
Cc: Ben Campbell , "dime@ietf.org" 
Subject: Re: [Dime] Updates to DOIC -05
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Dec 2014 10:25:21 -0000

Hi Steve,

   When a reporting node sends an OLR, it effectively delegates any
   necessary throttling to downstream nodes.  If the reporting node also
   locally throttles the same set of messages, the overall number of
   throttled request may be higher than intended.  Therefore, if a
s/throttled request/throttled requests
   reporting node needs to apply local throttling on a set of messages
   that match or overlap with existing OCS entries, it needs to consider
   the impact of throttling by downstream nodes.
s/throttling by/throttling performed by

question: what is the meaning of overlap here? Can we just kept "match"

   However, when the reporting node sends an OLR downstream, it might
   still need to apply other abatement methods such as diversion.  The
   reporting node might also need to throttle requests for reasons other
   than overload.  For example, an agent or server might have a
   configured rate limit for each client, and throttle requests that
   exceed that limit, even if such requests had already been candidates
   for throttling by downstream nodes.

I can live the text above.
But I would suggest to change the third sentence of the first paragraph as =
follow:

   Therefore, before applying local message throttling, a  reporting node
   needs to check if these messages match existing OCS entries, indicating
   that these messages have survived to the throttling applied by=20
   downstream nodes that have received the related OLR.

And to make the link the first paragraph and the second one, I would propos=
e:

   However, even if the set of messages match existing OCS entries, the=20
   reporting node can still apply other abatement methods such as diversion=
.=20=20
  [etc.]

Regards,

Lionel

-----Message d'origine-----
De=A0: Jouni [mailto:jouni.nospam@gmail.com]=20
Envoy=E9=A0: mercredi 3 d=E9cembre 2014 10:48
=C0=A0: Steve Donovan
Cc=A0: MORAND Lionel IMT/OLN; Ben Campbell; dime@ietf.org
Objet=A0: Re: [Dime] Updates to DOIC -05

I would be OK with this text.

- Jouni


> On 02 Dec 2014, at 20:49, Steve Donovan  wrote:
>=20
> Lionel,
>=20
> The two paragraphs together now say the following:
>=20
>    When a reporting node sends an OLR, it effectively delegates any
>    necessary throttling to downstream nodes.  If the reporting node also
>    locally throttles the same set of messages, the overall number of
>    throttled request may be higher than intended.  Therefore, if a
>    reporting node needs to apply local throttling on a set of messages
>    that match or overlap with existing OCS entries, it needs to consider
>    the impact of throttling by downstream nodes.
>=20
>    However, when the reporting node sends an OLR downstream, it might
>    still need to apply other abatement methods such as diversion.  The
>    reporting node might also need to throttle requests for reasons other
>    than overload.  For example, an agent or server might have a
>    configured rate limit for each client, and throttle requests that
>    exceed that limit, even if such requests had already been candidates
>    for throttling by downstream nodes.
>=20
> Do you see the need for further clarification?
>=20
> Steve
>=20
>=20
> On 11/25/14, 12:26 PM, lionel.morand@orange.com wrote:
>> I'm OK with the idea of the text proposed by Ben.
>> I would just make clear that throttling is applicable to the fact of sen=
ding/forwarding requests (cf. definition). A reporting node may apply local=
 throttling if it is an agent. But if it is a server, it can either drop th=
e exceeded number of requests (no response sent to the downstream) or send =
a specific DIAMETER-TOO-BUSY response. I think that this clarification is s=
omehow missing in the document.
>>=20
>> Regards,
>>=20
>> Lionel
>>=20
>> -----Message d'origine-----
>> De : Steve Donovan [
>> mailto:srdonovan@usdonovans.com
>> ]
>> Envoy=E9 : mardi 25 novembre 2014 15:07 =C0 : Ben Campbell; MORAND Lione=
l=20
>> IMT/OLN Cc : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org ; Maria=20
>> Cruz Bartolome Objet : Re: [Dime] Updates to DOIC -05
>>=20
>> I'm ok with Ben's wording and will make the change unless I hear objecti=
ons on the list.
>>=20
>> Steve
>>=20
>> On 11/21/14, 5:01 PM, Ben Campbell wrote:
>>=20
>>> On reflection, I think there might be a subtlety here. The resulting of=
fered-load may still exceed the reporting node's current capacity. This can=
 be true even if it's sent an OLR (and thus has related OCS). As mentioned =
in the surrounding node needs to still be able to protect itself, possibly =
by throttling. Therefore, I propose the sentence take the form of non-norma=
tive guidance. For example:
>>>=20
>>> "When a reporting node sends an OLR, it effectively delegates any neces=
sary throttling to downstream nodes.  If the reporting node also locally th=
rottles the same set of messages, the overall number of throttled request m=
ay be higher than intended. Therefore, if a reporting node needs to apply l=
ocal throttling on a set of messages that match or overlap with existing OC=
S entries, it needs to consider the impact of throttling by downstream node=
s."
>>>=20
>>>=20=20=20
>>>=20
>>>> On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com
>>>>  wrote:
>>>>=20
>>>> I can live with the text proposed by Ulrich. But what is wrong with:
>>>>=20
>>>> " Therefore, the reporting node SHOULD NOT apply throttling to the set=
 of messages to which an active OCS applies." ?
>>>>=20
>>>> Envoy=E9 depuis mon Sony Xperia SP d'Orange
>>>>=20
>>>> ---- Maria Cruz Bartolome a =E9crit ----
>>>>=20
>>>>=20
>>>>=20
>>>>> Section 4.2.3, 13th paragraph, 2nd sentence:
>>>>> Existing text: Therefore, the reporting node SHOULD NOT apply throttl=
ing to the set of messages to which the OLR applies.
>>>>> Proposed text: Therefore, the reporting node SHOULD NOT apply throttl=
ing to the set of messages to which the sent OLR applies.
>>>>>=20
>>>>> [LM] I would say that the reporting node will not remember the previo=
usly sent OLR, but will take care that there is an active OCS.
>>>>>=20
>>>> SRD> I'm ok with Ulrich's change.
>>>>=20
>>>> [LM] and this is incorrect but not fundamental. The reporting node doe=
s not have to "remember" a previously sent OLR. What it will do is to refer=
 to existing OCS to know that throttling should not be applied. An OCS is a=
 consequence of an sent OLR but it is not an OLR itself. But not fundamenta=
l here.
>>>>=20
>>>> [MCruz] I am ok with Ulrich's change. It does not mean that the report=
ing node needs to "remember" a previously sent OLR, though. The change only=
 proposes to "identify" which OLR we refer to.
>>>>=20
>>>> Best regards
>>>> /MCruz
>>>>=20
>>>>=20
>>>> ___________________________________________________________________
>>>> __ ____________________________________________________
>>>>=20
>>>> Ce message et ses pieces jointes peuvent contenir des informations=20
>>>> confidentielles ou privilegiees et ne doivent donc pas etre=20
>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20
>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru=
ire ainsi que les pieces jointes. Les messages electroniques etant suscepti=
bles d'alteration, Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>>>>=20
>>>> This message and its attachments may contain confidential or=20
>>>> privileged information that may be protected by law; they should not b=
e 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.
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>> _____________________________________________________________________
>> ____________________________________________________
>>=20
>> Ce message et ses pieces jointes peuvent contenir des informations=20
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
>> exploites ou copies sans autorisation. Si vous avez recu ce message=20
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=
 les pieces jointes. Les messages electroniques etant susceptibles d'altera=
tion, Orange decline toute responsabilite si ce message a ete altere, defor=
me ou falsifie. Merci.
>>=20
>> This message and its attachments may contain confidential or=20
>> 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 d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>>=20
>>=20
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.


From nobody Wed Dec  3 02:29:09 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393F21A1A06 for ; Wed,  3 Dec 2014 02:29:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level: 
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRfMngzlkJBh for ; Wed,  3 Dec 2014 02:29:02 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 547BD1A0461 for ; Wed,  3 Dec 2014 02:29:02 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id CDAFEA636CCF1; Wed,  3 Dec 2014 10:28:56 +0000 (GMT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sB3AT0PQ025173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Dec 2014 11:29:00 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.50]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 11:29:00 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: Steve Donovan , "lionel.morand@orange.com" , Ben Campbell 
Thread-Topic: [Dime] Updates to DOIC -05
Thread-Index: AQHP96zWh2IhAI9MNUyrs2P7h3In05xXdZWAgAKB9QCAABTjgIABToGAgABXjYCAAImqAIAAtOqAgAHz+gCAAFg3AIAFNTcAgAARHgCABzpwAIAFs+cAgABIhYCACwbhAIABEZ9g
Date: Wed, 3 Dec 2014 10:29:00 +0000
Message-ID: 
References: <545792B6.8030502@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, > <087A34937E64E74E848732CFF8354B9209863A54@ESESSMB101.ericsson.se> <24987_1416213505_5469B401_24987_4151_1_judb1lo2cnj5m4v6mdt5aec1.1416213483721@email.android.com>  <54748CEA.3020705@usdonovans.com> <19072_1416939968_5474C9C0_19072_1519_1_6B7134B31289DC4FAF731D844122B36E941639@PEXCVZYM13.corporate.adroot.infra.ftgroup> <547E09C0.5080305@usdonovans.com>
In-Reply-To: <547E09C0.5080305@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.41]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D2026F0FAFFR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/8OC75bZd98N5Oq93qskFOx73GWw
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Updates to DOIC -05
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Dec 2014 10:29:06 -0000

--_000_E194C2E18676714DACA9C3A2516265D2026F0FAFFR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear all

I am not against the new proposed texts from Steve or Ben to clarify this t=
opic.

My point is that, when  the reporting node has sent an OLR requiring  a tra=
ffic reduction , there is first a reaction time before receiving reduced tr=
affic, and second even if the traffic has been reduced, it can still exceed=
 the capacity of the reporting node  that has no other choice than to throt=
tle the received reduced traffic (if no diversion). This can happen when th=
e traffic at the source (reacting node) before throttling is increasing qui=
ckly, so the traffic reduced  according to the received OLR may  remain too=
 high .  Then, if the reporting node has nevertheless to do some throttle, =
it will certainly react by new OLRs requiring a higher traffic reduction fr=
om the reacting nodes. This is a dynamic process, where the reporting node =
adjust the  traffic  reduction it requires according to what it receives .

As Ben  I also think this is a guidance , and I think it is good to bring s=
ome guidance.

Best regards

JJacques

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mardi 2 d=E9cembre 2014 19:50
=C0 : lionel.morand@orange.com; Ben Campbell
Cc : dime@ietf.org
Objet : Re: [Dime] Updates to DOIC -05

Lionel,

The two paragraphs together now say the following:

   When a reporting node sends an OLR, it effectively delegates any

   necessary throttling to downstream nodes.  If the reporting node also

   locally throttles the same set of messages, the overall number of

   throttled request may be higher than intended.  Therefore, if a

   reporting node needs to apply local throttling on a set of messages

   that match or overlap with existing OCS entries, it needs to consider

   the impact of throttling by downstream nodes.



   However, when the reporting node sends an OLR downstream, it might

   still need to apply other abatement methods such as diversion.  The

   reporting node might also need to throttle requests for reasons other

   than overload.  For example, an agent or server might have a

   configured rate limit for each client, and throttle requests that

   exceed that limit, even if such requests had already been candidates

   for throttling by downstream nodes.
Do you see the need for further clarification?

Steve

On 11/25/14, 12:26 PM, lionel.morand@orange.com wrote:

I'm OK with the idea of the text proposed by Ben.

I would just make clear that throttling is applicable to the fact of sendin=
g/forwarding requests (cf. definition). A reporting node may apply local th=
rottling if it is an agent. But if it is a server, it can either drop the e=
xceeded number of requests (no response sent to the downstream) or send a s=
pecific DIAMETER-TOO-BUSY response. I think that this clarification is some=
how missing in the document.



Regards,



Lionel



-----Message d'origine-----

De : Steve Donovan [mailto:srdonovan@usdonovans.com]

Envoy=E9 : mardi 25 novembre 2014 15:07

=C0 : Ben Campbell; MORAND Lionel IMT/OLN

Cc : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; =
Maria Cruz Bartolome

Objet : Re: [Dime] Updates to DOIC -05



I'm ok with Ben's wording and will make the change unless I hear objections=
 on the list.



Steve



On 11/21/14, 5:01 PM, Ben Campbell wrote:

On reflection, I think there might be a subtlety here. The resulting offere=
d-load may still exceed the reporting node's current capacity. This can be =
true even if it's sent an OLR (and thus has related OCS). As mentioned in t=
he surrounding node needs to still be able to protect itself, possibly by t=
hrottling. Therefore, I propose the sentence take the form of non-normative=
 guidance. For example:



"When a reporting node sends an OLR, it effectively delegates any necessary=
 throttling to downstream nodes.  If the reporting node also locally thrott=
les the same set of messages, the overall number of throttled request may b=
e higher than intended. Therefore, if a reporting node needs to apply local=
 throttling on a set of messages that match or overlap with existing OCS en=
tries, it needs to consider the impact of throttling by downstream nodes."





On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com wrote:



I can live with the text proposed by Ulrich. But what is wrong with:



" Therefore, the reporting node SHOULD NOT apply throttling to the set of m=
essages to which an active OCS applies." ?



Envoy=E9 depuis mon Sony Xperia SP d'Orange



---- Maria Cruz Bartolome a =E9crit ----





Section 4.2.3, 13th paragraph, 2nd sentence:

Existing text: Therefore, the reporting node SHOULD NOT apply throttling to=
 the set of messages to which the OLR applies.

Proposed text: Therefore, the reporting node SHOULD NOT apply throttling to=
 the set of messages to which the sent OLR applies.



[LM] I would say that the reporting node will not remember the previously s=
ent OLR, but will take care that there is an active OCS.

SRD> I'm ok with Ulrich's change.



[LM] and this is incorrect but not fundamental. The reporting node does not=
 have to "remember" a previously sent OLR. What it will do is to refer to e=
xisting OCS to know that throttling should not be applied. An OCS is a cons=
equence of an sent OLR but it is not an OLR itself. But not fundamental her=
e.



[MCruz] I am ok with Ulrich's change. It does not mean that the reporting n=
ode needs to "remember" a previously sent OLR, though. The change only prop=
oses to "identify" which OLR we refer to.



Best regards

/MCruz





_____________________________________________________________________

____________________________________________________



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 le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n, 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 dis=
tributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and dele=
te 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

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime







___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.






--_000_E194C2E18676714DACA9C3A2516265D2026F0FAFFR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Dear all


 <=
/p>

I am not against the new =
proposed texts from Steve or Ben to clarify this topic.

 <=
/p>

My point is that, when &n=
bsp;the reporting node has sent an OLR requiring  a traffic reduction =
, there is first a reaction time before receiving reduced traffic,
 and second even if the traffic has been reduced, it can still exceed the c=
apacity of the reporting node  that has no other choice than to thrott=
le the received reduced traffic (if no diversion). This can happen when the=
 traffic at the source (reacting node)
 before throttling is increasing quickly, so the traffic reduced  acco=
rding to the received OLR may  remain too high .  Then, if the re=
porting node has nevertheless to do some throttle, it will certainly react =
by new OLRs requiring a higher traffic reduction
 from the reacting nodes. This is a dynamic process, where the reporting no=
de adjust the  traffic  reduction it requires according to what i=
t receives .


 <=
/p>

As Ben  I also think=
 this is a guidance , and I think it is good to bring some guidance.



 <=
/p>

Best regards


 <=
/p>

JJacques



 <=
/p>





De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mardi 2 d=E9cembre 2014 19:50

=C0 : lionel.morand@orange.com; Ben Campbell

Cc : dime@ietf.org

Objet : Re: [Dime] Updates to DOIC -05






 


Lionel,



The two paragraphs together now say the following:


   When a reporting node sends an OLR, it effectively delega=
tes any


   necessary throttling to downstream nodes.  If the re=
porting node also


   locally throttles the same set of messages, the overall n=
umber of


   throttled request may be higher than intended.  Ther=
efore, if a


   reporting node needs to apply local throttling on a set o=
f messages


   that match or overlap with existing OCS entries, it needs=
 to consider


   the impact of throttling by downstream nodes.<=
/pre>

 


   However, when the reporting node sends an OLR downstream,=
 it might


   still need to apply other abatement methods such as diver=
sion.  The


   reporting node might also need to throttle requests for r=
easons other


   than overload.  For example, an agent or server migh=
t have a


   configured rate limit for each client, and throttle reque=
sts that


   exceed that limit, even if such requests had already been=
 candidates


   for throttling by downstream nodes.


Do you see the need f=
or further clarification?



Steve








On 11/25/14, 12:26 PM, 
lionel.morand@orange.com wrote:






I'm OK with the idea of the text proposed by Ben.


I would just make clear that throttling is applicable to the fact of s=
ending/forwarding requests (cf. definition). A reporting node may apply loc=
al throttling if it is an agent. But if it is a server, it can either drop =
the exceeded number of requests (no response sent to the downstream) or sen=
d a specific DIAMETER-TOO-BUSY response. I think that this clarification is=
 somehow missing in the document.


 


Regards,


 


Lionel


 


-----Message d'origine-----


De : Steve Donovan [m=
ailto:srdonovan@usdonovans.com] 


Envoy=E9 : mardi 25 novembre 2014 15:07


=C0 : Ben Campbell; MORAND Lionel IMT/OLN


Cc : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; Maria Cruz Bartolome


Objet : Re: [Dime] Updates to DOIC -05


 


I'm ok with Ben's wording and will make the change unless I hear objec=
tions on the list.


 


Steve


 


On 11/21/14, 5:01 PM, Ben Campbell wrote:




On reflection, I think there might be a subtlety here. The resulting o=
ffered-load may still exceed the reporting node's current capacity. This ca=
n be true even if it's sent an OLR (and thus has related OCS). As mentioned=
 in the surrounding node needs to still be able to protect itself, possibly=
 by throttling. Therefore, I propose the sentence take the form of non-norm=
ative guidance. For example:


 


"When a reporting node sends an OLR, it effectively delegates any=
 necessary throttling to downstream nodes.  If the reporting node also=
 locally throttles the same set of messages, the overall number of throttle=
d request may be higher than intended. Therefore, if a reporting node needs=
 to apply local throttling on a set of messages that match or overlap with =
existing OCS entries, it needs to consider the impact of throttling by down=
stream nodes."


 


  




On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com wrote:


 


I can live with the text proposed by Ulrich. But what is wrong with:


 


" Therefore, the reporting node SHOULD NOT apply throttling to th=
e set of messages to which an active OCS applies." ?


 


Envoy=E9 depuis mon Sony Xperia SP d'Orange


 


---- Maria Cruz Bartolome a =E9crit ----


 


 




Section 4.2.3, 13th paragraph, 2nd sentence:


Existing text: Therefore, the reporting node SHOULD NOT apply throttli=
ng to the set of messages to which the OLR applies.


Proposed text: Therefore, the reporting node SHOULD NOT apply throttli=
ng to the set of messages to which the sent OLR applies.


 


[LM] I would say that the reporting node will not remember the previou=
sly sent OLR, but will take care that there is an active OCS.



SRD> I'm ok with Ulrich's change.


 


[LM] and this is incorrect but not fundamental. The reporting node doe=
s not have to "remember" a previously sent OLR. What it will do i=
s to refer to existing OCS to know that throttling should not be applied. A=
n OCS is a consequence of an sent OLR but it is not an OLR itself. But not =
fundamental here.


 


[MCruz] I am ok with Ulrich's change. It does not mean that the report=
ing node needs to "remember" a previously sent OLR, though. The c=
hange only proposes to "identify" which OLR we refer to.


 


Best regards


/MCruz


 


 


_____________________________________________________________________<=
o:p>


____________________________________________________


 


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 q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration, Orange decline toute responsabilite si ce message a ete altere, def=
orme ou falsifie. Merci.


 


This message and its attachments may contain confidential or 


privileged information that may be protected by law; they should not b=
e 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


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.


 


 




 






--_000_E194C2E18676714DACA9C3A2516265D2026F0FAFFR712WXCHMBA12z_--


From nobody Wed Dec  3 02:54:21 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF671A1A47 for ; Wed,  3 Dec 2014 02:54:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqSD_4193kQo for ; Wed,  3 Dec 2014 02:53:57 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ECBD1A00B7 for ; Wed,  3 Dec 2014 02:53:56 -0800 (PST)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 6332AC027F; Wed,  3 Dec 2014 11:53:54 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 3949A384061; Wed,  3 Dec 2014 11:53:54 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 11:53:53 +0100
From: 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Updated DOIC Requirements Analysis
Thread-Index: AQHQDl/RF5U9N06cVk+p/aHmphdv2px9rd8g
Date: Wed, 3 Dec 2014 10:53:52 +0000
Message-ID: <17153_1417604034_547EEBC2_17153_877_1_6B7134B31289DC4FAF731D844122B36E99A6E1@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <46C8B155-A8B0-41F6-A8A5-6F21D61ADE9E@nostrum.com> <16959_1416942163_5474D253_16959_819_1_6B7134B31289DC4FAF731D844122B36E941941@PEXCVZYM13.corporate.adroot.infra.ftgroup> <547E07E3.7090200@usdonovans.com>
In-Reply-To: <547E07E3.7090200@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.2]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E99A6E1PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.21.125720
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5nPX-F8gTNRLYYzqlPJ9P8DlpNI
Subject: Re: [Dime] Updated DOIC Requirements Analysis
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Dec 2014 10:54:12 -0000

--_000_6B7134B31289DC4FAF731D844122B36E99A6E1PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Steve,

For the first paragraph, I would simply say:


   This specification defines a base solution for Diameter overload

   control, referred to as Diameter Overload Indication Conveyance

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


OK for the rest.

Regards,

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mardi 2 d=E9cembre 2014 19:42
=C0 : dime@ietf.org
Objet : Re: [Dime] Updated DOIC Requirements Analysis

Lionel,

I currently have the following for the Introduction based on other suggesti=
ons 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, lionel.morand@orange.com wrote:

Hi Ben, Steve,



the text in section 1 needs also to be updated. I would propose something l=
ike:



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 woul=
d 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 ord=
er

   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 follow=
ing:



regards,



Lionel



De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell

Envoy=E9 : mardi 25 novembre 2014 03:19

=C0 : dime@ietf.org list

Objet : [Dime] Updated DOIC Requirements Analysis



Here's the text from the updated requirements analysis. I updated the summa=
ry 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 reser=
ved 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 confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime




___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.


--_000_6B7134B31289DC4FAF731D844122B36E99A6E1PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Steve,<=
o:p>


 =
;


For the fi=
rst paragraph, I would simply say:


 =
;


   This specification defines a base so=
lution for Diameter overload


   control, referred to as Diameter Ove=
rload Indication Conveyance


   (DOIC), based on the requirements id=
entified in RFC 7068 [RFC7068].


 


OK for the=
 rest.


 =
;


Regards,


 =
;


Lionel


 =
;






De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mardi 2 d=E9cembre 2014 19:42

=C0 : dime@ietf.org

Objet : Re: [Dime] Updated DOIC Requirements Analysis






 


Lionel,



I currently have the following for the Introduction based on other suggesti=
ons from, I believe, Ben:


   This specification defines a base solution for Diameter o=
verload


   control, referred to as Diameter Overload Indication Conv=
eyance


   (DOIC).  The requirements for the solution are descr=
ibed and


   discussed in the corresponding requirements document [RFC=
7068].


 


   This specification addresses Diameter overload control be=
tween


   Diameter nodes that support the DOIC solution.  The =
solution, which


   is designed to apply to existing and future Diameter appl=
ications,


   requires no changes to the Diameter base protocol [RFC673=
3] and is


   deployable in environments where some Diameter nodes do n=
ot implement


   the Diameter overload control solution defined in this sp=
ecification.


 


   Note that the overload control solution defined in this s=
pecification


   does not address all the requirements listed in [RFC7068]=
.  A number


   of overload control related features are left for future<=
o:p>


   specifications.  See Appendix A for a list of extens=
ions that are


   currently being considered.  See Appendix C for an a=
nalysis of


   conformance to the requirements specified in [RFC7068].


Let me know if this w=
orks for you.



I have included your other suggestion below.



Regards,



Steve








On 11/25/14, 1:02 PM, 
lionel.morand@orange.com wrote:






Hi Ben, Steve,


 


the text in section 1 needs also to be updated. I would propose someth=
ing like:


 


1.  Introduction


 


   This specification defines a base solution for Diameter O=
verload


   Control (DOC), referred to as Diameter Overload Indicatio=
n Conveyance


   (DOIC).  The requirements for the solution are descr=
ibed and


   discussed in the corresponding design requirements docume=
nt


   [RFC7068].  Note that the overload control solution =
defined in this


   specification does not address all the requirements liste=
d in


   [RFC7068].  See Appendix C for further details on th=
e 


   conformance to the requirements specified in [RFC706=
8].


 


In C.1:


 


C.1.  Deferred Requirements


 


   The DIME working group chose to defer certain requirement=
s in order


   to meet an an external deadline.  The 3GPP "Cor=
e 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 d=
eferred 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 no=
rmative


   reference in various Diameter related specifications to s=
upport the 


   overload control mechanism in their release 12 frame=
work.  The DIME


   working group has therefore decided to defer certain requ=
irements 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:dime-b=
ounces@ietf.org] De la part de Ben Campbell


Envoy=E9 : mardi 25 novembre 2014 03:19


=C0 : dime@ietf.org 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.&n=
bsp;


 


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 DO=
IC solutions


   conformance to the requirements defined in [RFC7068].


 


C.1.  Deferred Requirements


 


   The DIME working group chose to defer certain requirement=
s in order


   to meet an an external deadline.  The 3GPP "Cor=
e 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 d=
eferred work


   includes the following:


 


   o  Agent Overload - The ability for an agent to repo=
rt an overload


      condition of the agent itself.


 


   o  Load Information - The ability for a node to repo=
rt 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 su=
pporting


   nodes to automatically determine whether OC-Supported-Fea=
tures 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 im=
possible to


   detect the presence of non-supporting nodes between suppo=
rting nodes,


   except by configuration.  The working group determin=
ed that such a


   configuration requirement is acceptable.


 


   This limits full compliance with certain requirements rel=
ated to the


   limitation of new configuration, deployment in environmen=
ts with


   mixed support, operating across non-supporting agents, an=
d


   authorization.


 


C.3.  Implicit Application Indication


 


   The working group elected to determine the application fo=
r an


   overload report from that of the enclosing message. =
 This prevents


   sending an OLR for an application when there are no trans=
actions for


   that application.


 


   As a consequence, DOIC does not comply with the requireme=
nt to be


   able to report overload information across quiescent conn=
ections.


   DOIC does not fully comply with requirements to operate o=
n up-to-date


   information, since if an OLR causes all transactions to s=
top 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 eve=
ry answer


   message, as part of the requirement to avoid additional w=
ork for


   overloaded nodes.  DOIC recommends exactly that beha=
vior during


   active overload conditions.  The working group deter=
mined that doing


   otherwise would reduce reliability and increase statefuln=
ess.  (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 th=
e


   requirement to avoid introducing new vulnerabilities.&nbs=
p; However, this


   requirement may warrant an early security expert review.<=
o:p>


 


C.6.  Detailed Requirements


 


   [RFC Editor: Please remove this section and subsections p=
rior to


   publication as an RFC.]


 


C.6.1.  General


 


   REQ 1:  The solution MUST provide a communication me=
thod for Diameter


           nodes to =
exchange load and overload information.


 


           *Partiall=
y Compliant*. The mechanism uses new AVPs


           piggyback=
ed on existing Diameter messages to exchange


           overload =
information.  It does not currently support "load"


           informati=
on or the ability to report overload of an agent.


           These hav=
e been left for future extensions.


 


 


 


   REQ 2:  The solution MUST allow Diameter nodes to su=
pport overload


           control r=
egardless of which Diameter applications they


           support.&=
nbsp; 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 ove=
rload conditions is best described by REQ 3.


 


           *Partiall=
y Compliant*. The DOIC AVPs can be used in any


           applicati=
on that allows the extension of AVPs.  However,


           "loa=
d" information is not currently supported.


 


 


 


   REQ 3:  The solution MUST limit the impact of overlo=
ad on the overall


           useful th=
roughput 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.


 


           *Complian=
t*. DOIC provides information that nodes can use to


           reduce th=
e impact of overload.


 


 


 


   REQ 4:  Diameter allows requests to be sent from eit=
her side of a


           connectio=
n, and either side of a connection may have need to


           provide i=
ts overload status.  The solution MUST allow each


           side of a=
 connection to independently inform the other of its


           overload =
status.


 


           *Complian=
t*. DOIC AVPs can be included regardless of


           transacti=
on "direction"


 


 


 


   REQ 5:  Diameter allows nodes to determine their pee=
rs via dynamic


           discovery=
 or manual configuration.  The solution MUST work


           consisten=
tly without regard to how peers are determined.


 


           *Complian=
t*. DOIC contains no assumptions about how peers are


           discovere=
d.


 


 


 


   REQ 6:  The solution designers SHOULD seek to minimi=
ze the amount of


           new confi=
guration required in order to work.  For example, it


           is better=
 to allow peers to advertise or negotiate support


           for the s=
olution, rather than to require that this knowledge


           to be con=
figured at each node.


 


           *Partiall=
y Compliant*. Most DOIC parameters are advertised


           using the=
 DOIC capability announcement mechanism.  However,


           there are=
 some situations where configuration is required.


           For examp=
le, a DOIC node detect the fact that a peer may not


           support D=
OIC when nodes on the other side of the non-


           supportin=
g node do support DOIC without configuration.


 


 


 


C.6.2.  Performance


 


   REQ 7:  The solution and any associated default algo=
rithm(s) MUST


           ensure th=
at the system remains stable.  At some point after


           an overlo=
ad condition has ended, the solution MUST enable


           capacity =
to stabilize and become equal to what it would be in


           the absen=
ce of an overload condition.  Note that this also


           requires =
that the solution MUST allow nodes to shed load


           without i=
ntroducing non-converging oscillations during or


           after an =
overload condition.


 


           *Complian=
t*. The specification offers guidance that


           implement=
ations should apply hysteresis when recovering from


           overload,=
 and avoid sudden ramp ups in offered load when


           recoverin=
g.


 


 


 


   REQ 8:  Supporting nodes MUST be able to distinguish=
 current overload


           informati=
on from stale information.


 


           *Partiall=
y Compliant*. DOIC overload reports are "soft


           state&quo=
t;, that is they expire after an indicated period.  DOIC

           nodes may=
 also send reports that end existing overload


           condition=
s.  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 w=
atchdog messages, if an overload condition results


           in zero o=
ffered load, the reporting node cannot update the


           condition=
 until the expiration of the original OLR.


 


 


 


   REQ 9:  The solution MUST function across fully load=
ed as well as


           quiescent=
 transport connections.  This is partially derived


           from the =
requirement for stability in REQ 7.


 


           *Not Comp=
liant*. 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 appl=
y.


 


 


 


   REQ 10: Consumers of overload information MUST be able to=
 determine


           when the =
overload condition improves or ends.


 


           *Partiall=
y Compliant*. (See response to previous two


           requireme=
nts.)


 


 


 


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


           sizes.


 


           *Complian=
t*. DOIC makes no assumptions about the size of the


           network.&=
nbsp; DOIC can operate purely between clients and


           servers, =
or across agents.


 


 


 


   REQ 12: When a single network node fails, goes into overl=
oad, or


           suffers f=
rom reduced processing capacity, the solution MUST


           make it p=
ossible to limit the impact of the affected node on


           other nod=
es in the network.  This helps to prevent a small-


           scale fai=
lure from becoming a widespread outage.


 


           *Partiall=
y Compliant*. DOIC allows overload reports for an


           entire re=
alm, where abated traffic will not be redirected


           towards a=
nother server.  But in situations where nodes choose


           to divert=
 traffic to other nodes, DOIC offers no way of


           knowing w=
hether 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 o=
f proprietary dynamic load-balancing mechanisms.


 


 


 


   REQ 13: The solution MUST NOT introduce substantial addit=
ional work


           for a nod=
e in an overloaded state.  For example, a


           requireme=
nt for an overloaded node to send overload


           informati=
on every time it received a new request would


           introduce=
 substantial work.


 


           *Not Comp=
liant*. DOIC does in fact encourage an overloaded


           node to s=
end an OLR in every response.  The working group


           that othe=
r mechanisms to ensure that every relevant node


           receives =
an OLR would create even more work.  [Note: This


           needs dis=
cussion.]


 


 


 


   REQ 14: Some scenarios that result in overload involve a =
rapid


           increase =
of traffic with little time between normal levels


           and level=
s that induce overload.  The solution SHOULD provide


           for rapid=
 feedback when traffic levels increase.


 


           *Complian=
t*. The piggyback mechanism allows OLRs to be sent


           at the sa=
me rate as application traffic.


 


 


 


   REQ 15: The solution MUST NOT interfere with the congesti=
on control


           mechanism=
s of underlying transport protocols.  For example, a


           solution =
that opened additional TCP connections when the


           network i=
s congested would reduce the effectiveness of the


           underlyin=
g congestion control mechanisms.


 


           *Complian=
t*. DOIC does not require or recommend changes in


           the handl=
ing of transport protocols or connections.


 


 


 


C.6.3.  Heterogeneous Support for Solution


 


   REQ 16: The solution is likely to be deployed incremental=
ly.  The


           solution =
MUST support a mixed environment where some, but not


           all, node=
s implement it.


 


           *Partiall=
y Compliant*. DOIC works with most mixed-deployment


           scenarios=
.  However, it cannot work across a non-supporting


           proxy tha=
t modifies Origin-Host AVPs in answer messages.


           DOIC will=
 have limited impact in networks where the nodes


           that perf=
orm server selections do not support the mechanism.


 


 


 


   REQ 17: In a mixed environment with nodes that support th=
e solution


           and nodes=
 that do not, the solution MUST NOT result in


           materiall=
y less useful throughput during overload as would


           have resu=
lted if the solution were not present.  It SHOULD


           result in=
 less severe overload in this environment.


 


           *Complian=
t*. 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 tha=
t do not, the solution MUST NOT preclude elements


           that supp=
ort overload control from treating elements that do


           not suppo=
rt overload control in an equitable fashion relative


           to those =
that do.  Users and operators of nodes that do not


           support t=
he solution MUST NOT unfairly benefit from the


           solution.=
  The solution specification SHOULD provide guidance


           to implem=
entors for dealing with elements not supporting


           overload =
control.


 


           *Complian=
t*. DOIC provides mechanisms to abate load from non-


           supportin=
g sources.  Furthermore, it recommends that


           reporting=
 nodes will still need to be able to apply whatever


           protectio=
ns they would ordinarily apply if DOIC were not in


           use.=



 


 


 


   REQ 19: It MUST be possible to use the solution between n=
odes in


           different=
 realms and in different administrative domains.


 


           *Partiall=
y Compliant*. DOIC allows sending OLRs across


           administr=
ative domains, and potentially to nodes in other


           realms.&n=
bsp; However, an OLR cannot indicate overload for realms


           other tha=
n the one in the Origin-Realm AVP of the containing


           answer.


 


 


 


   REQ 20: Any explicit overload indication MUST be clearly<=
o:p>


           distingui=
shable from other errors reported via Diameter.


 


           *Complian=
t*. 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 overlo=
aded that it


           cannot pr=
ocess messages, or cannot communicate due to a


           network f=
ailure, it may not be able to provide explicit


           indicatio=
ns of the nature of the failure or its levels of


           overload.=
  The solution MUST result in at least as much


           useful th=
roughput as would have resulted if the solution were


           not in pl=
ace.


 


           *Complian=
t*. DOIC overload reports have the primary effect of


           suppressi=
ng message retries in overload conditions.  DOIC


           recommend=
s 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 thr=
ottle the


           amount of=
 traffic it receives from a peer node.  This


           throttlin=
g SHOULD be graded so that it can be applied


           gradually=
 as offered load increases.  Overload is not a


           binary st=
ate; there may be degrees of overload.


 


           *Complian=
t*. The "loss" algorithm expresses a percentage


           reduction=
.


 


 


 


   REQ 23: The solution MUST provide sufficient information =
to enable a


           load-bala=
ncing 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 Comp=
liant*. 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 &q=
uot;load" extension, or with proprietary load balancing

           mechanism=
s.


 


 


 


   REQ 24: The solution MUST provide a mechanism for indicat=
ing load


           levels, e=
ven when not in an overload condition, to assist


           nodes in =
making decisions to prevent overload conditions from


           occurring=
.


 


           *Not Comp=
liant*. "Load" information has been left for a


           future ex=
tension.


 


 


 


C.6.5.  Priority and Policy


 


   REQ 25: The base specification for the solution SHOULD of=
fer general


           guidance =
on which message types might be desirable to send or


           process o=
ver others during times of overload, based on


           applicati=
on-specific considerations.  For example, it may be


           more bene=
ficial to process messages for existing sessions


           ahead of =
new sessions.  Some networks may have a requirement


           to give p=
riority to requests associated with emergency


           sessions.=
  Any normative or otherwise detailed definition of


           the relat=
ive priorities of message types during an overload


           condition=
 will be the responsibility of the application


           specifica=
tion.


 


           *Complian=
t*. The specification offers guidance on how


           requests =
might be prioritized for different types of


           applicati=
ons.


 


 


 


   REQ 26: The solution MUST NOT prevent a node from priorit=
izing


           requests =
based on any local policy, so that certain requests


           are given=
 preferential treatment, given additional


           retransmi=
ssion, not throttled, or processed ahead of others.


 


           *Complian=
t*. Nothing in the specification prevents


           applicati=
on-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


           vulnerabi=
lities.  This includes vulnerabilities to DoS and


           DDoS atta=
cks as well as replay and man-in-the-middle attacks.


           Note that=
 the Diameter base specification [RFC6733] lacks


           end-to-en=
d security and this must be considered (see the


           Security =
Considerations in [RFC7068]).  Note that this


           requireme=
nt 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.


 


           *Complian=
t*. The working group is not aware of any such


           vulnerabi=
lities.  [This may need further analysis.]


 


 


 


   REQ 28: The solution MUST NOT depend on being deployed in=



           environme=
nts where all Diameter nodes are completely trusted.


           It SHOULD=
 operate as effectively as possible in environments


           where oth=
er nodes are malicious; this includes preventing


           malicious=
 nodes from obtaining more than a fair share of


           service.&=
nbsp; Note that this does not imply any responsibility on


           the solut=
ion to detect, or take countermeasures against,


           malicious=
 nodes.


 


           *Partiall=
y Compliant*. Since all Diameter security is


           currently=
 at the transport layer, nodes must trust immediate


           peers to =
enforce trust policies.  However, there are


           situation=
s where a DOIC node cannot determine if an immediate


           peer supp=
orts DOIC.  The authors recommend an expert security


           review.


 


 


 


   REQ 29: It MUST be possible for a supporting node to make=



           authoriza=
tion decisions about what information will be sent


           to peer n=
odes 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


           informati=
on.  Of course, in such cases, there is no


           expectati=
on that the solution itself will help prevent


           overload =
from that peer node.


 


           *Partiall=
y Compliant*. (See response to previous


           requireme=
nt.)


 


 


 


   REQ 30: The solution MUST NOT interfere with any Diameter=
-compliant


           method th=
at a node may use to protect itself from overload


           from non-=
supporting nodes or from denial-of-service attacks.


 


           *Complian=
t*. The specification recommends that any such


           protectio=
n mechanism needed without DOIC should continue to


           be employ=
ed with DOIC.


 


 


 


C.6.7.  Flexibility and Extensibility


 


   REQ 31: There are multiple situations where a Diameter no=
de may be


           overloade=
d for some purposes but not others.  For example,


           this can =
happen to an agent or server that supports multiple


           applicati=
ons, 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 indica=
te overload with sufficient granularity to allow


           clients t=
o take action based on the overloaded resources


           without u=
nreasonably forcing available capacity to go unused.


           The solut=
ion MUST support specification of overload


           informati=
on with granularities of at least "Diameter node",

           "rea=
lm", and "Diameter application" and MUST allow

           extensibi=
lity for others to be added in the future.


 


           *Partiall=
y Compliant*. All DOIC overload reports are scoped


           to the sp=
ecific application and realm.  Inside that scope,


           overload =
can be reported at the specific server or whole


           realm sco=
pe.  As currently specified, DOIC cannot indicate


           local ove=
rload for an agent.  At the time of this writing,


           the DIME =
working group has plans to work on an agent-overload


           extension=
.


 


           DOIC allo=
ws new "scopes" through the use of extended report

           types.


 


 


 


   REQ 32: The solution MUST provide a method for extending =
the


           informati=
on communicated and the algorithms used for overload


           control.<=
o:p>


 


           *Complian=
t*. DOIC allows new report types and abatement


           algorithm=
s to be created.  These may be indicated using the


           OC-Suppor=
ted-Features AVP.


 


 


 


   REQ 33: The solution MUST provide a default algorithm tha=
t is


           mandatory=
 to implement.


 


           *Complian=
t*. The "loss" algorithm is mandatory to implement.

 


 


 


   REQ 34: The solution SHOULD provide a method for exchangi=
ng overload


           and load =
information between elements that are connected by


           intermedi=
aries that do not support the solution.


 


           *Partiall=
y Compliant*. DOIC information can traverse non-


           supportin=
g agents, as long as those agents do not modify


           certain A=
VPs. (e.g., Origin-Host).  DOIC does not provide a


           way for s=
upporting nodes to detect such modification.


 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 




______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.




--_000_6B7134B31289DC4FAF731D844122B36E99A6E1PEXCVZYM13corpora_--


From nobody Wed Dec  3 02:55:24 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2323C1A1A47 for ; Wed,  3 Dec 2014 02:55:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level: 
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nA-L_aGwEam1 for ; Wed,  3 Dec 2014 02:55:18 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16EF01A1A3E for ; Wed,  3 Dec 2014 02:55:18 -0800 (PST)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id E05E51903D1; Wed,  3 Dec 2014 11:55:15 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id BD5B13840BD; Wed,  3 Dec 2014 11:55:15 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 11:55:15 +0100
From: 
To: Jouni , "dime@ietf.org list" 
Thread-Topic: Call for WG adoption: draft-donovan-dime-doc-rate-control
Thread-Index: AQHQDuGZxrULykDx2EG5Hg1F50yWbpx9sVqA
Date: Wed, 3 Dec 2014 10:55:13 +0000
Message-ID: <17900_1417604115_547EEC13_17900_1759_1_6B7134B31289DC4FAF731D844122B36E99A6FD@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.2]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.21.125720
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/s4YMraLJYVjIC-LBvaEry_LCY4k
Subject: Re: [Dime] Call for WG adoption: draft-donovan-dime-doc-rate-control
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Dec 2014 10:55:19 -0000

As individual, I support.

Lionel

-----Message d'origine-----
De=A0: Jouni [mailto:jouni.nospam@gmail.com]=20
Envoy=E9=A0: mercredi 3 d=E9cembre 2014 11:12
=C0=A0: dime@ietf.org list
Cc=A0: MORAND Lionel IMT/OLN; Jouni
Objet=A0: Call for WG adoption: draft-donovan-dime-doc-rate-control

Folks,

As we discussed and agreed during the Honolulu meeting we ask for the WG ad=
option for draft-donovan-dime-doc-rate-control unless counter proposals sho=
w up. The "wait period" for counter proposals has been more than enough.

This mail starts a two week adoption call for draft-donovan-dime-doc-rate-c=
ontrol as a WG Item.

Express your support or disagreements in the mailing list. The call ends 17=
th Dec EOB (CET+1).

- Jouni & Lionel


___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.


From nobody Wed Dec  3 02:55:35 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B94E1A1A74 for ; Wed,  3 Dec 2014 02:55:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level: 
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXJ09Ck6iMRD for ; Wed,  3 Dec 2014 02:55:32 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE6F1A1A47 for ; Wed,  3 Dec 2014 02:55:31 -0800 (PST)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id C31342AC528; Wed,  3 Dec 2014 11:55:27 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 6D950180096; Wed,  3 Dec 2014 11:55:27 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 11:55:27 +0100
From: 
To: Jouni , "dime@ietf.org list" 
Thread-Topic: Call for WG adoption: draft-donovan-dime-agent-overload
Thread-Index: AQHQDuGe1AwI6w9Xxka8illnZAylz5x9sYHQ
Date: Wed, 3 Dec 2014 10:55:26 +0000
Message-ID: <24870_1417604127_547EEC1F_24870_1587_1_6B7134B31289DC4FAF731D844122B36E99A707@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <32615952-7107-45B6-85AD-AD9F57FBE418@gmail.com>
In-Reply-To: <32615952-7107-45B6-85AD-AD9F57FBE418@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.2]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.21.125720
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/lM3JFFRiJ6yYpAlFmP7zwQUIWnw
Subject: Re: [Dime] Call for WG adoption: draft-donovan-dime-agent-overload
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Dec 2014 10:55:34 -0000

As individual, I support.

Lionel

-----Message d'origine-----
De=A0: Jouni [mailto:jouni.nospam@gmail.com]=20
Envoy=E9=A0: mercredi 3 d=E9cembre 2014 11:12
=C0=A0: dime@ietf.org list
Cc=A0: MORAND Lionel IMT/OLN; Jouni
Objet=A0: Call for WG adoption: draft-donovan-dime-agent-overload

Folks,

As we discussed and agreed during the Honolulu meeting we ask for the WG ad=
option for draft-donovan-dime-agent-overload unless counter proposals show =
up. The "wait period" for counter proposals has been more than enough.

This mail starts a two week adoption call for draft-donovan-dime-agent-over=
load as a WG Item.

Express your support or disagreements in the mailing list. The call ends 17=
th Dec EOB (CET+1).

- Jouni & Lionel


___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.


From nobody Wed Dec  3 04:19:48 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3D91A1A7A for ; Wed,  3 Dec 2014 04:19:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level: 
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNITs5-C2hZs for ; Wed,  3 Dec 2014 04:19:31 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E2981A1A96 for ; Wed,  3 Dec 2014 04:19:30 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 1227BDEC67002; Wed,  3 Dec 2014 12:19:26 +0000 (GMT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sB3CJRt0024112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Dec 2014 13:19:27 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.50]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 13:19:28 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: Steve Donovan , "lionel.morand@orange.com" , Ben Campbell 
Thread-Topic: [Dime] Updates to DOIC -05
Thread-Index: AQHP96zWh2IhAI9MNUyrs2P7h3In05xXdZWAgAKB9QCAABTjgIABToGAgABXjYCAAImqAIAAtOqAgAHz+gCAAFg3AIAFNTcAgAARHgCABzpwAIAFs+cAgABIhYCACwbhAIABEZ9ggAAii9A=
Date: Wed, 3 Dec 2014 12:19:27 +0000
Message-ID: 
References: <545792B6.8030502@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815228ADC@DEMUMBX014.nsn-intra.net> <22181_1415728795_54624E9B_22181_12987_1_6B7134B31289DC4FAF731D844122B36E8C86C9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, > <087A34937E64E74E848732CFF8354B9209863A54@ESESSMB101.ericsson.se> <24987_1416213505_5469B401_24987_4151_1_judb1lo2cnj5m4v6mdt5aec1.1416213483721@email.android.com>  <54748CEA.3020705@usdonovans.com> <19072_1416939968_5474C9C0_19072_1519_1_6B7134B31289DC4FAF731D844122B36E941639@PEXCVZYM13.corporate.adroot.infra.ftgroup> <547E09C0.5080305@usdonovans.com> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.41]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D2026F1036FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qmnpwKZnTmjc612IzyI_xKPBnTU
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Updates to DOIC -05
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Dec 2014 12:19:46 -0000

--_000_E194C2E18676714DACA9C3A2516265D2026F1036FR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear all

To continue on my remark , I would complement the Steve's text with " can u=
pdate the reduction of traffic it requires from the reacting nodes(s) by se=
nding new overload reports" as hereafter:



   Therefore, if a

   reporting node needs to apply local throttling on a set of messages

   that match existing OCS entries, it needs to consider

   the impact of throttling by downstream nodes and can update the reductio=
n of traffic it requires from the reacting nodes(s) by sending new overload=
 reports.


Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Envoy=E9 : mercredi 3 d=E9cembre 2014 11:29
=C0 : Steve Donovan; lionel.morand@orange.com; Ben Campbell
Cc : dime@ietf.org
Objet : Re: [Dime] Updates to DOIC -05

Dear all

I am not against the new proposed texts from Steve or Ben to clarify this t=
opic.

My point is that, when  the reporting node has sent an OLR requiring  a tra=
ffic reduction , there is first a reaction time before receiving reduced tr=
affic, and second even if the traffic has been reduced, it can still exceed=
 the capacity of the reporting node  that has no other choice than to throt=
tle the received reduced traffic (if no diversion). This can happen when th=
e traffic at the source (reacting node) before throttling is increasing qui=
ckly, so the traffic reduced  according to the received OLR may  remain too=
 high .  Then, if the reporting node has nevertheless to do some throttle, =
it will certainly react by new OLRs requiring a higher traffic reduction fr=
om the reacting nodes. This is a dynamic process, where the reporting node =
adjust the  traffic  reduction it requires according to what it receives .

As Ben  I also think this is a guidance , and I think it is good to bring s=
ome guidance.

Best regards

JJacques

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mardi 2 d=E9cembre 2014 19:50
=C0 : lionel.morand@orange.com; Ben Campbe=
ll
Cc : dime@ietf.org
Objet : Re: [Dime] Updates to DOIC -05

Lionel,

The two paragraphs together now say the following:

   When a reporting node sends an OLR, it effectively delegates any

   necessary throttling to downstream nodes.  If the reporting node also

   locally throttles the same set of messages, the overall number of

   throttled request may be higher than intended.  Therefore, if a

   reporting node needs to apply local throttling on a set of messages

   that match or overlap with existing OCS entries, it needs to consider

   the impact of throttling by downstream nodes.



   However, when the reporting node sends an OLR downstream, it might

   still need to apply other abatement methods such as diversion.  The

   reporting node might also need to throttle requests for reasons other

   than overload.  For example, an agent or server might have a

   configured rate limit for each client, and throttle requests that

   exceed that limit, even if such requests had already been candidates

   for throttling by downstream nodes.
Do you see the need for further clarification?

Steve
On 11/25/14, 12:26 PM, lionel.morand@orange.com wrote:

I'm OK with the idea of the text proposed by Ben.

I would just make clear that throttling is applicable to the fact of sendin=
g/forwarding requests (cf. definition). A reporting node may apply local th=
rottling if it is an agent. But if it is a server, it can either drop the e=
xceeded number of requests (no response sent to the downstream) or send a s=
pecific DIAMETER-TOO-BUSY response. I think that this clarification is some=
how missing in the document.



Regards,



Lionel



-----Message d'origine-----

De : Steve Donovan [mailto:srdonovan@usdonovans.com]

Envoy=E9 : mardi 25 novembre 2014 15:07

=C0 : Ben Campbell; MORAND Lionel IMT/OLN

Cc : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; =
Maria Cruz Bartolome

Objet : Re: [Dime] Updates to DOIC -05



I'm ok with Ben's wording and will make the change unless I hear objections=
 on the list.



Steve



On 11/21/14, 5:01 PM, Ben Campbell wrote:

On reflection, I think there might be a subtlety here. The resulting offere=
d-load may still exceed the reporting node's current capacity. This can be =
true even if it's sent an OLR (and thus has related OCS). As mentioned in t=
he surrounding node needs to still be able to protect itself, possibly by t=
hrottling. Therefore, I propose the sentence take the form of non-normative=
 guidance. For example:



"When a reporting node sends an OLR, it effectively delegates any necessary=
 throttling to downstream nodes.  If the reporting node also locally thrott=
les the same set of messages, the overall number of throttled request may b=
e higher than intended. Therefore, if a reporting node needs to apply local=
 throttling on a set of messages that match or overlap with existing OCS en=
tries, it needs to consider the impact of throttling by downstream nodes."





On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com wrote:



I can live with the text proposed by Ulrich. But what is wrong with:



" Therefore, the reporting node SHOULD NOT apply throttling to the set of m=
essages to which an active OCS applies." ?



Envoy=E9 depuis mon Sony Xperia SP d'Orange



---- Maria Cruz Bartolome a =E9crit ----





Section 4.2.3, 13th paragraph, 2nd sentence:

Existing text: Therefore, the reporting node SHOULD NOT apply throttling to=
 the set of messages to which the OLR applies.

Proposed text: Therefore, the reporting node SHOULD NOT apply throttling to=
 the set of messages to which the sent OLR applies.



[LM] I would say that the reporting node will not remember the previously s=
ent OLR, but will take care that there is an active OCS.

SRD> I'm ok with Ulrich's change.



[LM] and this is incorrect but not fundamental. The reporting node does not=
 have to "remember" a previously sent OLR. What it will do is to refer to e=
xisting OCS to know that throttling should not be applied. An OCS is a cons=
equence of an sent OLR but it is not an OLR itself. But not fundamental her=
e.



[MCruz] I am ok with Ulrich's change. It does not mean that the reporting n=
ode needs to "remember" a previously sent OLR, though. The change only prop=
oses to "identify" which OLR we refer to.



Best regards

/MCruz





_____________________________________________________________________

____________________________________________________



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 le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n, 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 dis=
tributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and dele=
te 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

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime







___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.






--_000_E194C2E18676714DACA9C3A2516265D2026F1036FR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Dear all


 <=
/p>

To continue on my remark =
, I would complement the Steve’s text with “
can update the reduction of traffic it requires from the reacting nodes(s)=
 by sending new overload reports”
as hereafter:    


 


   Therefore, if a


   reporting node needs to apply local throttling on a set o=
f messages


   that match existing OCS entries, it needs to consider


   the impact of throttling by downstream nodes and can upda=
te the reduction of traffic it requires from the reacting nodes(s) by sendi=
ng new overload reports. 


 


Best regards


 <=
/p>

JJacques



 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Envoy=E9 : mercredi 3 d=E9cembre 2014 11:29

=C0 : Steve Donovan; lionel.morand@orange.com; Ben Campbell

Cc : dime@ietf.org

Objet : Re: [Dime] Updates to DOIC -05






 


Dear all


 <=
/p>

I am not against the new =
proposed texts from Steve or Ben to clarify this topic.

 <=
/p>

My point is that, when &n=
bsp;the reporting node has sent an OLR requiring  a traffic reduction =
, there is first a reaction time before receiving reduced traffic,
 and second even if the traffic has been reduced, it can still exceed the c=
apacity of the reporting node  that has no other choice than to thrott=
le the received reduced traffic (if no diversion). This can happen when the=
 traffic at the source (reacting node)
 before throttling is increasing quickly, so the traffic reduced  acco=
rding to the received OLR may  remain too high .  Then, if the re=
porting node has nevertheless to do some throttle, it will certainly react =
by new OLRs requiring a higher traffic reduction
 from the reacting nodes. This is a dynamic process, where the reporting no=
de adjust the  traffic  reduction it requires according to what i=
t receives .


 <=
/p>

As Ben  I also think=
 this is a guidance , and I think it is good to bring some guidance.



 <=
/p>

Best regards


 <=
/p>

JJacques



 <=
/p>





De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mardi 2 d=E9cembre 2014 19:50

=C0 : lionel.morand=
@orange.com; Ben Campbell

Cc : dime@ietf.org

Objet : Re: [Dime] Updates to DOIC -05






 


Lionel,



The two paragraphs together now say the following:


   When a reporting node sends an OLR, it effectively delega=
tes any


   necessary throttling to downstream nodes.  If the re=
porting node also


   locally throttles the same set of messages, the overall n=
umber of


   throttled request may be higher than intended.  Ther=
efore, if a


   reporting node needs to apply local throttling on a set o=
f messages


   that match or overlap with existing OCS entries, it needs=
 to consider


   the impact of throttling by downstream nodes.<=
/pre>

 


   However, when the reporting node sends an OLR downstream,=
 it might


   still need to apply other abatement methods such as diver=
sion.  The


   reporting node might also need to throttle requests for r=
easons other


   than overload.  For example, an agent or server migh=
t have a


   configured rate limit for each client, and throttle reque=
sts that


   exceed that limit, even if such requests had already been=
 candidates


   for throttling by downstream nodes.


Do you see the need f=
or further clarification?



Steve




On 11/25/14, 12:26 PM, 
lionel.morand@orange.com wrote:






I'm OK with the idea of the text proposed by Ben.


I would just make clear that throttling is applicable to the fact of s=
ending/forwarding requests (cf. definition). A reporting node may apply loc=
al throttling if it is an agent. But if it is a server, it can either drop =
the exceeded number of requests (no response sent to the downstream) or sen=
d a specific DIAMETER-TOO-BUSY response. I think that this clarification is=
 somehow missing in the document.


 


Regards,


 


Lionel


 


-----Message d'origine-----


De : Steve Donovan [m=
ailto:srdonovan@usdonovans.com] 


Envoy=E9 : mardi 25 novembre 2014 15:07


=C0 : Ben Campbell; MORAND Lionel IMT/OLN


Cc : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; Maria Cruz Bartolome


Objet : Re: [Dime] Updates to DOIC -05


 


I'm ok with Ben's wording and will make the change unless I hear objec=
tions on the list.


 


Steve


 


On 11/21/14, 5:01 PM, Ben Campbell wrote:




On reflection, I think there might be a subtlety here. The resulting o=
ffered-load may still exceed the reporting node's current capacity. This ca=
n be true even if it's sent an OLR (and thus has related OCS). As mentioned=
 in the surrounding node needs to still be able to protect itself, possibly=
 by throttling. Therefore, I propose the sentence take the form of non-norm=
ative guidance. For example:


 


"When a reporting node sends an OLR, it effectively delegates any=
 necessary throttling to downstream nodes.  If the reporting node also=
 locally throttles the same set of messages, the overall number of throttle=
d request may be higher than intended. Therefore, if a reporting node needs=
 to apply local throttling on a set of messages that match or overlap with =
existing OCS entries, it needs to consider the impact of throttling by down=
stream nodes."


 


  




On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com wrote:


 


I can live with the text proposed by Ulrich. But what is wrong with:


 


" Therefore, the reporting node SHOULD NOT apply throttling to th=
e set of messages to which an active OCS applies." ?


 


Envoy=E9 depuis mon Sony Xperia SP d'Orange


 


---- Maria Cruz Bartolome a =E9crit ----


 


 




Section 4.2.3, 13th paragraph, 2nd sentence:


Existing text: Therefore, the reporting node SHOULD NOT apply throttli=
ng to the set of messages to which the OLR applies.


Proposed text: Therefore, the reporting node SHOULD NOT apply throttli=
ng to the set of messages to which the sent OLR applies.


 


[LM] I would say that the reporting node will not remember the previou=
sly sent OLR, but will take care that there is an active OCS.



SRD> I'm ok with Ulrich's change.


 


[LM] and this is incorrect but not fundamental. The reporting node doe=
s not have to "remember" a previously sent OLR. What it will do i=
s to refer to existing OCS to know that throttling should not be applied. A=
n OCS is a consequence of an sent OLR but it is not an OLR itself. But not =
fundamental here.


 


[MCruz] I am ok with Ulrich's change. It does not mean that the report=
ing node needs to "remember" a previously sent OLR, though. The c=
hange only proposes to "identify" which OLR we refer to.


 


Best regards


/MCruz


 


 


_____________________________________________________________________<=
o:p>


____________________________________________________


 


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 q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration, Orange decline toute responsabilite si ce message a ete altere, def=
orme ou falsifie. Merci.


 


This message and its attachments may contain confidential or 


privileged information that may be protected by law; they should not b=
e 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


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.


 


 




 






--_000_E194C2E18676714DACA9C3A2516265D2026F1036FR712WXCHMBA12z_--


From nobody Wed Dec  3 05:30:00 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076671A1AFB for ; Wed,  3 Dec 2014 05:29:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ut37tF6kQGop for ; Wed,  3 Dec 2014 05:29:56 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C3A1A1AF4 for ; Wed,  3 Dec 2014 05:29:55 -0800 (PST)
Received: from [10.0.1.11] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB3DTo7S058166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Dec 2014 07:29:51 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.11]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <17900_1417604115_547EEC13_17900_1759_1_6B7134B31289DC4FAF731D844122B36E99A6FD@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Date: Wed, 3 Dec 2014 07:29:49 -0600
X-Mao-Original-Outgoing-Id: 439306189.770499-f02219789bef8ce0f8ca63f7e06695ba
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <17900_1417604115_547EEC13_17900_1759_1_6B7134B31289DC4FAF731D844122B36E99A6FD@PEXCVZYM13.corporate.adroot.infra.ftgroup>
To: lionel.morand@orange.com
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ntKAVikyWicSr09DZh6n1TMbtxg
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Call for WG adoption: draft-donovan-dime-doc-rate-control
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Dec 2014 13:29:58 -0000

I support adoption.

> On Dec 3, 2014, at 4:55 AM, lionel.morand@orange.com wrote:
>=20
> As individual, I support.
>=20
> Lionel
>=20
> -----Message d'origine-----
> De : Jouni [mailto:jouni.nospam@gmail.com]=20
> Envoy=E9 : mercredi 3 d=E9cembre 2014 11:12
> =C0 : dime@ietf.org list
> Cc : MORAND Lionel IMT/OLN; Jouni
> Objet : Call for WG adoption: draft-donovan-dime-doc-rate-control
>=20
> Folks,
>=20
> As we discussed and agreed during the Honolulu meeting we ask for the =
WG adoption for draft-donovan-dime-doc-rate-control unless counter =
proposals show up. The "wait period" for counter proposals has been more =
than enough.
>=20
> This mail starts a two week adoption call for =
draft-donovan-dime-doc-rate-control as a WG Item.
>=20
> Express your support or disagreements in the mailing list. The call =
ends 17th Dec EOB (CET+1).
>=20
> - Jouni & Lionel
>=20
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> 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.
>=20
> 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.
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Dec  3 05:30:23 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3116C1A1A99 for ; Wed,  3 Dec 2014 05:30:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wwTSbfP5twh for ; Wed,  3 Dec 2014 05:30:16 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9751A1AFB for ; Wed,  3 Dec 2014 05:30:15 -0800 (PST)
Received: from [10.0.1.11] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB3DTo7T058166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Dec 2014 07:30:14 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.11]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <24870_1417604127_547EEC1F_24870_1587_1_6B7134B31289DC4FAF731D844122B36E99A707@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Date: Wed, 3 Dec 2014 07:30:13 -0600
X-Mao-Original-Outgoing-Id: 439306213.716126-9eef3bb4ee3e75ff0272e391a5d0b223
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <32615952-7107-45B6-85AD-AD9F57FBE418@gmail.com> <24870_1417604127_547EEC1F_24870_1587_1_6B7134B31289DC4FAF731D844122B36E99A707@PEXCVZYM13.corporate.adroot.infra.ftgroup>
To: lionel.morand@orange.com
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dkNQ57QXQxTQJqYrJNM3Lkfbmco
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Call for WG adoption: draft-donovan-dime-agent-overload
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Dec 2014 13:30:20 -0000

I support adoption.

/Ben

> On Dec 3, 2014, at 4:55 AM, lionel.morand@orange.com wrote:
>=20
> As individual, I support.
>=20
> Lionel
>=20
> -----Message d'origine-----
> De : Jouni [mailto:jouni.nospam@gmail.com]=20
> Envoy=E9 : mercredi 3 d=E9cembre 2014 11:12
> =C0 : dime@ietf.org list
> Cc : MORAND Lionel IMT/OLN; Jouni
> Objet : Call for WG adoption: draft-donovan-dime-agent-overload
>=20
> Folks,
>=20
> As we discussed and agreed during the Honolulu meeting we ask for the =
WG adoption for draft-donovan-dime-agent-overload unless counter =
proposals show up. The "wait period" for counter proposals has been more =
than enough.
>=20
> This mail starts a two week adoption call for =
draft-donovan-dime-agent-overload as a WG Item.
>=20
> Express your support or disagreements in the mailing list. The call =
ends 17th Dec EOB (CET+1).
>=20
> - Jouni & Lionel
>=20
>=20
> =
__________________________________________________________________________=
_______________________________________________
>=20
> 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.
>=20
> 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.
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Dec  3 05:45:45 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAAA1A1B1F for ; Wed,  3 Dec 2014 05:45:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcTPk7oqfSzX for ; Wed,  3 Dec 2014 05:45:43 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F3F1A1B15 for ; Wed,  3 Dec 2014 05:45:43 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:56496 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XwAFN-0007p7-O0 for dime@ietf.org; Wed, 03 Dec 2014 05:45:43 -0800
Message-ID: <547F1401.1020804@usdonovans.com>
Date: Wed, 03 Dec 2014 07:45:37 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: dime@ietf.org
References:  <17900_1417604115_547EEC13_17900_1759_1_6B7134B31289DC4FAF731D844122B36E99A6FD@PEXCVZYM13.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/6jNqCJ0kUMvdKZZVdbYngD7VGpo
Subject: Re: [Dime] Call for WG adoption: draft-donovan-dime-doc-rate-control
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Dec 2014 13:45:45 -0000

+1

On 12/3/14, 7:29 AM, Ben Campbell wrote:
> I support adoption.
>
>> On Dec 3, 2014, at 4:55 AM, lionel.morand@orange.com wrote:
>>
>> As individual, I support.
>>
>> Lionel
>>
>> -----Message d'origine-----
>> De : Jouni [mailto:jouni.nospam@gmail.com]
>> Envoyé : mercredi 3 décembre 2014 11:12
>> À : dime@ietf.org list
>> Cc : MORAND Lionel IMT/OLN; Jouni
>> Objet : Call for WG adoption: draft-donovan-dime-doc-rate-control
>>
>> Folks,
>>
>> As we discussed and agreed during the Honolulu meeting we ask for the WG adoption for draft-donovan-dime-doc-rate-control unless counter proposals show up. The "wait period" for counter proposals has been more than enough.
>>
>> This mail starts a two week adoption call for draft-donovan-dime-doc-rate-control as a WG Item.
>>
>> Express your support or disagreements in the mailing list. The call ends 17th Dec EOB (CET+1).
>>
>> - Jouni & Lionel
>>
>>
>> _________________________________________________________________________________________________________________________
>>
>> 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
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Wed Dec  3 05:46:09 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBAB1A1B15 for ; Wed,  3 Dec 2014 05:46:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_Gv5bAxrQON for ; Wed,  3 Dec 2014 05:46:00 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB861A0461 for ; Wed,  3 Dec 2014 05:46:00 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:56497 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XwAFj-0008Fq-8w for dime@ietf.org; Wed, 03 Dec 2014 05:46:00 -0800
Message-ID: <547F1417.1090803@usdonovans.com>
Date: Wed, 03 Dec 2014 07:45:59 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: dime@ietf.org
References: <32615952-7107-45B6-85AD-AD9F57FBE418@gmail.com> <24870_1417604127_547EEC1F_24870_1587_1_6B7134B31289DC4FAF731D844122B36E99A707@PEXCVZYM13.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/T1HNV8ASMFaL5ApFY2sOuEEb1hY
Subject: Re: [Dime] Call for WG adoption: draft-donovan-dime-agent-overload
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Dec 2014 13:46:08 -0000

+1

On 12/3/14, 7:30 AM, Ben Campbell wrote:
> I support adoption.
>
> /Ben
>
>> On Dec 3, 2014, at 4:55 AM, lionel.morand@orange.com wrote:
>>
>> As individual, I support.
>>
>> Lionel
>>
>> -----Message d'origine-----
>> De : Jouni [mailto:jouni.nospam@gmail.com]
>> Envoyé : mercredi 3 décembre 2014 11:12
>> À : dime@ietf.org list
>> Cc : MORAND Lionel IMT/OLN; Jouni
>> Objet : Call for WG adoption: draft-donovan-dime-agent-overload
>>
>> Folks,
>>
>> As we discussed and agreed during the Honolulu meeting we ask for the WG adoption for draft-donovan-dime-agent-overload unless counter proposals show up. The "wait period" for counter proposals has been more than enough.
>>
>> This mail starts a two week adoption call for draft-donovan-dime-agent-overload as a WG Item.
>>
>> Express your support or disagreements in the mailing list. The call ends 17th Dec EOB (CET+1).
>>
>> - Jouni & Lionel
>>
>>
>> _________________________________________________________________________________________________________________________
>>
>> 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
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Wed Dec  3 09:02:20 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA5E1A89FC for ; Wed,  3 Dec 2014 09:02:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-Yj7UlsZABC for ; Wed,  3 Dec 2014 09:02:06 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792C21A1B47 for ; Wed,  3 Dec 2014 09:01:59 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:56803 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XwDJG-0001KM-KI; Wed, 03 Dec 2014 09:01:57 -0800
Message-ID: <547F41FE.1050300@usdonovans.com>
Date: Wed, 03 Dec 2014 11:01:50 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: lionel.morand@orange.com, "dime@ietf.org" 
References: <46C8B155-A8B0-41F6-A8A5-6F21D61ADE9E@nostrum.com> <16959_1416942163_5474D253_16959_819_1_6B7134B31289DC4FAF731D844122B36E941941@PEXCVZYM13.corporate.adroot.infra.ftgroup> <547E07E3.7090200@usdonovans.com> <17153_1417604034_547EEBC2_17153_877_1_6B7134B31289DC4FAF731D844122B36E99A6E1@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <17153_1417604034_547EEBC2_17153_877_1_6B7134B31289DC4FAF731D844122B36E99A6E1@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------080001050808030500030600"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7OGhS5J_3d6lElTDUqJRIu25KcE
Subject: Re: [Dime] Updated DOIC Requirements Analysis
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Dec 2014 17:02:14 -0000

This is a multi-part message in MIME format.
--------------080001050808030500030600
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Change made.

On 12/3/14, 4:53 AM, lionel.morand@orange.com wrote:
>
> Hi Steve,
>
> For the first paragraph, I would simply say:
>
>     This specification defines a base solution for Diameter overload
>     control, referred to as Diameter Overload Indication Conveyance
>     (DOIC), based on the requirements identified in RFC 7068 [RFC7068].
>   
>
> OK for the rest.
>
> Regards,
>
> Lionel
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve Donovan
> *Envoyé :* mardi 2 décembre 2014 19:42
> *À :* dime@ietf.org
> *Objet :* Re: [Dime] Updated DOIC Requirements Analysis
>
> 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, lionel.morand@orange.com 
>  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:dime-bounces@ietf.org] De la part de Ben Campbell
>
>     Envoyé : mardi 25 novembre 2014 03:19
>
>     À :dime@ietf.org    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
>
>     DiME@ietf.org  
>
>     https://www.ietf.org/mailman/listinfo/dime
>
>       
>
> _________________________________________________________________________________________________________________________
>
> 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.


--------------080001050808030500030600
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Change made.

    

    
On 12/3/14, 4:53 AM,
      lionel.morand@orange.com wrote:

    

    

      
      
      
      

        
Hi Steve,

        
 

        
For the first paragraph, I would simply say:

        
 

        
   This specification defines a base solution for Diameter overload

        
   control, referred to as Diameter Overload Indication Conveyance

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

        
 

        
OK for the rest.

        
 

        
Regards,

        
 

        
Lionel

        
 

        

          

            
De :
                DiME [mailto:dime-bounces@ietf.org]
                De la part de Steve Donovan

                Envoyé : mardi 2 décembre 2014 19:42

                À : dime@ietf.org

                Objet : Re: [Dime] Updated DOIC Requirements
                Analysis

          

        

        
 

        
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, 
              lionel.morand@orange.com 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:dime-bounces@ietf.org] De la part de Ben Campbell

          
Envoyé : mardi 25 novembre 2014 03:19

          
À : dime@ietf.org 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

          
DiME@ietf.org

          
https://www.ietf.org/mailman/listinfo/dime

          
 

        

        
 

      

      
_________________________________________________________________________________________________________________________

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.


    

    

  


--------------080001050808030500030600--


From nobody Wed Dec  3 09:23:01 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257DB1A1BFC for ; Wed,  3 Dec 2014 09:22:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x54V-tuKfXhG for ; Wed,  3 Dec 2014 09:22:37 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3881A1B32 for ; Wed,  3 Dec 2014 09:22:37 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:56854 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XwDdF-0003BW-Uh; Wed, 03 Dec 2014 09:22:35 -0800
Message-ID: <547F46D5.7060800@usdonovans.com>
Date: Wed, 03 Dec 2014 11:22:29 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" ,  "lionel.morand@orange.com" ,  Ben Campbell 
References: <545792B6.8030502@usdonovans.com> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, > <087A34937E64E74E848732CFF8354B9209863A54@ESESSMB101.ericsson.se> <24987_1416213505_5469B401_24987_4151_1_judb1lo2cnj5m4v6mdt5aec1.1416213483721@email.android.com>  <54748CEA.3020705@usdonovans.com> <19072_1416939968_5474C9C0_19072_1519_1_6B7134B31289DC4FAF731D844122B36E941639@PEXCVZYM13.corporate.adroot.infra.ftgroup> <547E09C0.5080305@usdonovans.com>  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050306050307030703060007"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/oymA3JTcFZnQQKRfmOMDKYPxcqA
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Updates to DOIC -05
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Dec 2014 17:22:47 -0000

This is a multi-part message in MIME format.
--------------050306050307030703060007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

I have attempted to address both Lionel's and Jean-Jacques' suggestions 
with the following text:

    When a reporting node sends an OLR, it effectively delegates any
    necessary throttling to downstream nodes.  If the reporting node also
    locally throttles the same set of messages, the overall number of
    throttled requests may be higher than intended.  Therefore, before
    applying local message throttling, a reporting node needs to check if
    these messages match existing OCS entries, indicating that these
    messages have survived throttling applied by downstream nodes that
    have received the related OLR.

    However, even if the set of messages match existing OCS entries, the
    reporting node can still apply other abatement methods such as
    diversion.  The reporting node might also need to throttle requests
    for reasons other than overload.  For example, an agent or server
    might have a configured rate limit for each client, and throttle
    requests that exceed that limit, even if such requests had already
    been candidates for throttling by downstream nodes.  The reporting
    node also has the option to send new OLRs requesting greater
    reductions in traffic, reducing the need for local throttling.


Steve

On 12/3/14, 6:19 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
> Dear all
>
> To continue on my remark , I would complement the Steve's text with " 
> can update the reduction of traffic it requires from the reacting 
> nodes(s) by sending new overload reports" as hereafter:
>
>   
>     Therefore, if a
>     reporting node needs to apply local throttling on a set of messages
>     that match existing OCS entries, it needs to consider
>     the impact of throttling by downstream nodes and can update the reduction of traffic it requires from the reacting nodes(s) by sending new overload reports.
>   
>
> Best regards
>
> JJacques
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* TROTTIN, 
> JEAN-JACQUES (JEAN-JACQUES)
> *Envoyé :* mercredi 3 décembre 2014 11:29
> *À :* Steve Donovan; lionel.morand@orange.com; Ben Campbell
> *Cc :* dime@ietf.org
> *Objet :* Re: [Dime] Updates to DOIC -05
>
> Dear all
>
> I am not against the new proposed texts from Steve or Ben to clarify 
> this topic.
>
> My point is that, when  the reporting node has sent an OLR requiring 
>  a traffic reduction , there is first a reaction time before receiving 
> reduced traffic, and second even if the traffic has been reduced, it 
> can still exceed the capacity of the reporting node  that has no other 
> choice than to throttle the received reduced traffic (if no 
> diversion). This can happen when the traffic at the source (reacting 
> node) before throttling is increasing quickly, so the traffic reduced  
> according to the received OLR may  remain too high .  Then, if the 
> reporting node has nevertheless to do some throttle, it will certainly 
> react by new OLRs requiring a higher traffic reduction from the 
> reacting nodes. This is a dynamic process, where the reporting node 
> adjust the  traffic  reduction it requires according to what it receives .
>
> As Ben  I also think this is a guidance , and I think it is good to 
> bring some guidance.
>
> Best regards
>
> JJacques
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve Donovan
> *Envoyé :* mardi 2 décembre 2014 19:50
> *À :* lionel.morand@orange.com ; Ben 
> Campbell
> *Cc :* dime@ietf.org 
> *Objet :* Re: [Dime] Updates to DOIC -05
>
> Lionel,
>
> The two paragraphs together now say the following:
>
>     When a reporting node sends an OLR, it effectively delegates any
>     necessary throttling to downstream nodes.  If the reporting node also
>     locally throttles the same set of messages, the overall number of
>     throttled request may be higher than intended.  Therefore, if a
>     reporting node needs to apply local throttling on a set of messages
>     that match or overlap with existing OCS entries, it needs to consider
>     the impact of throttling by downstream nodes.
>   
>     However, when the reporting node sends an OLR downstream, it might
>     still need to apply other abatement methods such as diversion.  The
>     reporting node might also need to throttle requests for reasons other
>     than overload.  For example, an agent or server might have a
>     configured rate limit for each client, and throttle requests that
>     exceed that limit, even if such requests had already been candidates
>     for throttling by downstream nodes.
>
> Do you see the need for further clarification?
>
> Steve
>
> On 11/25/14, 12:26 PM, lionel.morand@orange.com 
>  wrote:
>
>     I'm OK with the idea of the text proposed by Ben.
>
>     I would just make clear that throttling is applicable to the fact of sending/forwarding requests (cf. definition). A reporting node may apply local throttling if it is an agent. But if it is a server, it can either drop the exceeded number of requests (no response sent to the downstream) or send a specific DIAMETER-TOO-BUSY response. I think that this clarification is somehow missing in the document.
>
>       
>
>     Regards,
>
>       
>
>     Lionel
>
>       
>
>     -----Message d'origine-----
>
>     De : Steve Donovan [mailto:srdonovan@usdonovans.com]
>
>     Envoyé : mardi 25 novembre 2014 15:07
>
>     À : Ben Campbell; MORAND Lionel IMT/OLN
>
>     Cc : Wiehe, Ulrich (NSN - DE/Munich);dime@ietf.org  ; Maria Cruz Bartolome
>
>     Objet : Re: [Dime] Updates to DOIC -05
>
>       
>
>     I'm ok with Ben's wording and will make the change unless I hear objections on the list.
>
>       
>
>     Steve
>
>       
>
>     On 11/21/14, 5:01 PM, Ben Campbell wrote:
>
>         On reflection, I think there might be a subtlety here. The resulting offered-load may still exceed the reporting node's current capacity. This can be true even if it's sent an OLR (and thus has related OCS). As mentioned in the surrounding node needs to still be able to protect itself, possibly by throttling. Therefore, I propose the sentence take the form of non-normative guidance. For example:
>
>           
>
>         "When a reporting node sends an OLR, it effectively delegates any necessary throttling to downstream nodes.  If the reporting node also locally throttles the same set of messages, the overall number of throttled request may be higher than intended. Therefore, if a reporting node needs to apply local throttling on a set of messages that match or overlap with existing OCS entries, it needs to consider the impact of throttling by downstream nodes."
>
>           
>
>            
>
>             On Nov 17, 2014, at 2:38 AM,lionel.morand@orange.com    wrote:
>
>               
>
>             I can live with the text proposed by Ulrich. But what is wrong with:
>
>               
>
>             " Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which an active OCS applies." ?
>
>               
>
>             Envoyé depuis mon Sony Xperia SP d'Orange
>
>               
>
>             ---- Maria Cruz Bartolome a écrit ----
>
>               
>
>               
>
>                 Section 4.2.3, 13th paragraph, 2nd sentence:
>
>                 Existing text: Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the OLR applies.
>
>                 Proposed text: Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the sent OLR applies.
>
>                   
>
>                 [LM] I would say that the reporting node will not remember the previously sent OLR, but will take care that there is an active OCS.
>
>             SRD> I'm ok with Ulrich's change.
>
>               
>
>             [LM] and this is incorrect but not fundamental. The reporting node does not have to "remember" a previously sent OLR. What it will do is to refer to existing OCS to know that throttling should not be applied. An OCS is a consequence of an sent OLR but it is not an OLR itself. But not fundamental here.
>
>               
>
>             [MCruz] I am ok with Ulrich's change. It does not mean that the reporting node needs to "remember" a previously sent OLR, though. The change only proposes to "identify" which OLR we refer to.
>
>               
>
>             Best regards
>
>             /MCruz
>
>               
>
>               
>
>             _____________________________________________________________________
>
>             ____________________________________________________
>
>               
>
>             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
>
>             DiME@ietf.org  
>
>             https://www.ietf.org/mailman/listinfo/dime
>
>           
>
>       
>
>       
>
>     _________________________________________________________________________________________________________________________
>
>       
>
>     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.
>
>       
>
>       
>


--------------050306050307030703060007
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I have attempted to address both Lionel's and Jean-Jacques'
    suggestions with the following text:

    

    
    
   When a reporting node sends an OLR, it effectively delegates any
   necessary throttling to downstream nodes.  If the reporting node also
   locally throttles the same set of messages, the overall number of
   throttled requests may be higher than intended.  Therefore, before
   applying local message throttling, a reporting node needs to check if
   these messages match existing OCS entries, indicating that these
   messages have survived throttling applied by downstream nodes that
   have received the related OLR.

   However, even if the set of messages match existing OCS entries, the
   reporting node can still apply other abatement methods such as
   diversion.  The reporting node might also need to throttle requests
   for reasons other than overload.  For example, an agent or server
   might have a configured rate limit for each client, and throttle
   requests that exceed that limit, even if such requests had already
   been candidates for throttling by downstream nodes.  The reporting
   node also has the option to send new OLRs requesting greater
   reductions in traffic, reducing the need for local throttling.

    

    Steve

    

    
On 12/3/14, 6:19 AM, TROTTIN,
      JEAN-JACQUES (JEAN-JACQUES) wrote:

    

    

      
      
      
      

        
Dear
            all

        
 

        
To
            continue on my remark , I would complement the Steve’s text
            with “
          can update the reduction of traffic it requires
            from the reacting nodes(s) by sending new overload reports”
          as
            hereafter:    

        
 

        
   Therefore, if a

        
   reporting node needs to apply local throttling on a set of messages

        
   that match existing OCS entries, it needs to consider

        
   the impact of throttling by downstream nodes and can update the reduction of traffic it requires from the reacting nodes(s) by sending new overload reports. 

        
 

        
Best
            regards

        
 

        
JJacques
            

        
 

        
 

        

          

            
De : DiME [mailto:dime-bounces@ietf.org]
                De la part de TROTTIN, JEAN-JACQUES
                (JEAN-JACQUES)

                Envoyé : mercredi 3 décembre 2014 11:29

                À : Steve Donovan; lionel.morand@orange.com; Ben
                Campbell

                Cc : dime@ietf.org

                Objet : Re: [Dime] Updates to DOIC -05

          

        

        
 

        
Dear
            all

        
 

        
I
            am not against the new proposed texts from Steve or Ben to
            clarify this topic.

        
 

        
My
            point is that, when  the reporting node has sent an OLR
            requiring  a traffic reduction , there is first a reaction
            time before receiving reduced traffic, and second even if
            the traffic has been reduced, it can still exceed the
            capacity of the reporting node  that has no other choice
            than to throttle the received reduced traffic (if no
            diversion). This can happen when the traffic at the source
            (reacting node) before throttling is increasing quickly, so
            the traffic reduced  according to the received OLR may
             remain too high .  Then, if the reporting node has
            nevertheless to do some throttle, it will certainly react by
            new OLRs requiring a higher traffic reduction from the
            reacting nodes. This is a dynamic process, where the
            reporting node adjust the  traffic  reduction it requires
            according to what it receives .

        
 

        
As
            Ben  I also think this is a guidance , and I think it is
            good to bring some guidance.
            

        
 

        
Best
            regards

        
 

        
JJacques
            

        
 

        

          

            
De : DiME [mailto:dime-bounces@ietf.org]
                De la part de Steve Donovan

                Envoyé : mardi 2 décembre 2014 19:50

                À : lionel.morand@orange.com;
                Ben Campbell

                Cc : dime@ietf.org

                Objet : Re: [Dime] Updates to DOIC -05

          

        

        
 

        
Lionel,

          

          The two paragraphs together now say the following:

        
   When a reporting node sends an OLR, it effectively delegates any

        
   necessary throttling to downstream nodes.  If the reporting node also

        
   locally throttles the same set of messages, the overall number of

        
   throttled request may be higher than intended.  Therefore, if a

        
   reporting node needs to apply local throttling on a set of messages

        
   that match or overlap with existing OCS entries, it needs to consider

        
   the impact of throttling by downstream nodes.

        
 

        
   However, when the reporting node sends an OLR downstream, it might

        
   still need to apply other abatement methods such as diversion.  The

        
   reporting node might also need to throttle requests for reasons other

        
   than overload.  For example, an agent or server might have a

        
   configured rate limit for each client, and throttle requests that

        
   exceed that limit, even if such requests had already been candidates

        
   for throttling by downstream nodes.

        
Do you see the
          need for further clarification?

          

          Steve

        

          
On 11/25/14, 12:26 PM, 
              lionel.morand@orange.com wrote:

        

        

          
I'm OK with the idea of the text proposed by Ben.

          
I would just make clear that throttling is applicable to the fact of sending/forwarding requests (cf. definition). A reporting node may apply local throttling if it is an agent. But if it is a server, it can either drop the exceeded number of requests (no response sent to the downstream) or send a specific DIAMETER-TOO-BUSY response. I think that this clarification is somehow missing in the document.

          
 

          
Regards,

          
 

          
Lionel

          
 

          
-----Message d'origine-----

          
De : Steve Donovan [mailto:srdonovan@usdonovans.com] 

          
Envoyé : mardi 25 novembre 2014 15:07

          
À : Ben Campbell; MORAND Lionel IMT/OLN

          
Cc : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; Maria Cruz Bartolome

          
Objet : Re: [Dime] Updates to DOIC -05

          
 

          
I'm ok with Ben's wording and will make the change unless I hear objections on the list.

          
 

          
Steve

          
 

          
On 11/21/14, 5:01 PM, Ben Campbell wrote:

          

            
On reflection, I think there might be a subtlety here. The resulting offered-load may still exceed the reporting node's current capacity. This can be true even if it's sent an OLR (and thus has related OCS). As mentioned in the surrounding node needs to still be able to protect itself, possibly by throttling. Therefore, I propose the sentence take the form of non-normative guidance. For example:

            
 

            
"When a reporting node sends an OLR, it effectively delegates any necessary throttling to downstream nodes.  If the reporting node also locally throttles the same set of messages, the overall number of throttled request may be higher than intended. Therefore, if a reporting node needs to apply local throttling on a set of messages that match or overlap with existing OCS entries, it needs to consider the impact of throttling by downstream nodes."

            
 

            
  

            

              
On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com wrote:

              
 

              
I can live with the text proposed by Ulrich. But what is wrong with:

              
 

              
" Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which an active OCS applies." ?

              
 

              
Envoyé depuis mon Sony Xperia SP d'Orange

              
 

              
---- Maria Cruz Bartolome a écrit ----

              
 

              
 

              

                
Section 4.2.3, 13th paragraph, 2nd sentence:

                
Existing text: Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the OLR applies.

                
Proposed text: Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the sent OLR applies.

                
 

                
[LM] I would say that the reporting node will not remember the previously sent OLR, but will take care that there is an active OCS.

              

              
SRD> I'm ok with Ulrich's change.

              
 

              
[LM] and this is incorrect but not fundamental. The reporting node does not have to "remember" a previously sent OLR. What it will do is to refer to existing OCS to know that throttling should not be applied. An OCS is a consequence of an sent OLR but it is not an OLR itself. But not fundamental here.

              
 

              
[MCruz] I am ok with Ulrich's change. It does not mean that the reporting node needs to "remember" a previously sent OLR, though. The change only proposes to "identify" which OLR we refer to.

              
 

              
Best regards

              
/MCruz

              
 

              
 

              
_____________________________________________________________________

              
____________________________________________________

              
 

              
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

              
DiME@ietf.org

              
https://www.ietf.org/mailman/listinfo/dime

            

            
 

          

          
 

          
 

          
_________________________________________________________________________________________________________________________

          
 

          
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.

          
 

          
 

        

        
 

      

    

    

  


--------------050306050307030703060007--


From nobody Wed Dec  3 09:50:01 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF20E1A8AE2 for ; Wed,  3 Dec 2014 09:49:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wztyl6HwCTDy for ; Wed,  3 Dec 2014 09:49:41 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD281A8AD9 for ; Wed,  3 Dec 2014 09:49:41 -0800 (PST)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 388AE18C042; Wed,  3 Dec 2014 18:49:39 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1C0742380DD; Wed,  3 Dec 2014 18:49:39 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 18:49:38 +0100
From: 
To: Steve Donovan , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , Ben Campbell 
Thread-Topic: [Dime] Updates to DOIC -05
Thread-Index: AQHQDmC9B2lc+qnTi0KtXgvGw5tH5Jx9mmIAgAAe3ICAAFSqgIAAGEsg
Date: Wed, 3 Dec 2014 17:49:38 +0000
Message-ID: <19906_1417628979_547F4D33_19906_1955_1_6B7134B31289DC4FAF731D844122B36E99DE18@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <545792B6.8030502@usdonovans.com> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, > <087A34937E64E74E848732CFF8354B9209863A54@ESESSMB101.ericsson.se> <24987_1416213505_5469B401_24987_4151_1_judb1lo2cnj5m4v6mdt5aec1.1416213483721@email.android.com>  <54748CEA.3020705@usdonovans.com> <19072_1416939968_5474C9C0_19072_1519_1_6B7134B31289DC4FAF731D844122B36E941639@PEXCVZYM13.corporate.adroot.infra.ftgroup> <547E09C0.5080305@usdonovans.com>   <547F46D5.7060800@usdonovans.com>
In-Reply-To: <547F46D5.7060800@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.4]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E99DE18PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.21.125720
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/s5Df5RSvhLTNK_k_NSE0V_ym3nw
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Updates to DOIC -05
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Dec 2014 17:49:56 -0000

--_000_6B7134B31289DC4FAF731D844122B36E99DE18PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I'm fine with the modified text.

Lionel

De : Steve Donovan [mailto:srdonovan@usdonovans.com]
Envoy=E9 : mercredi 3 d=E9cembre 2014 18:22
=C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); MORAND Lionel IMT/OLN; Ben Camp=
bell
Cc : dime@ietf.org
Objet : Re: [Dime] Updates to DOIC -05

I have attempted to address both Lionel's and Jean-Jacques' suggestions wit=
h the following text:

   When a reporting node sends an OLR, it effectively delegates any

   necessary throttling to downstream nodes.  If the reporting node also

   locally throttles the same set of messages, the overall number of

   throttled requests may be higher than intended.  Therefore, before

   applying local message throttling, a reporting node needs to check if

   these messages match existing OCS entries, indicating that these

   messages have survived throttling applied by downstream nodes that

   have received the related OLR.



   However, even if the set of messages match existing OCS entries, the

   reporting node can still apply other abatement methods such as

   diversion.  The reporting node might also need to throttle requests

   for reasons other than overload.  For example, an agent or server

   might have a configured rate limit for each client, and throttle

   requests that exceed that limit, even if such requests had already

   been candidates for throttling by downstream nodes.  The reporting

   node also has the option to send new OLRs requesting greater

   reductions in traffic, reducing the need for local throttling.

Steve
On 12/3/14, 6:19 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
Dear all

To continue on my remark , I would complement the Steve's text with " can u=
pdate the reduction of traffic it requires from the reacting nodes(s) by se=
nding new overload reports" as hereafter:



   Therefore, if a

   reporting node needs to apply local throttling on a set of messages

   that match existing OCS entries, it needs to consider

   the impact of throttling by downstream nodes and can update the reductio=
n of traffic it requires from the reacting nodes(s) by sending new overload=
 reports.


Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Envoy=E9 : mercredi 3 d=E9cembre 2014 11:29
=C0 : Steve Donovan; lionel.morand@orange.com; Ben Campbell
Cc : dime@ietf.org
Objet : Re: [Dime] Updates to DOIC -05

Dear all

I am not against the new proposed texts from Steve or Ben to clarify this t=
opic.

My point is that, when  the reporting node has sent an OLR requiring  a tra=
ffic reduction , there is first a reaction time before receiving reduced tr=
affic, and second even if the traffic has been reduced, it can still exceed=
 the capacity of the reporting node  that has no other choice than to throt=
tle the received reduced traffic (if no diversion). This can happen when th=
e traffic at the source (reacting node) before throttling is increasing qui=
ckly, so the traffic reduced  according to the received OLR may  remain too=
 high .  Then, if the reporting node has nevertheless to do some throttle, =
it will certainly react by new OLRs requiring a higher traffic reduction fr=
om the reacting nodes. This is a dynamic process, where the reporting node =
adjust the  traffic  reduction it requires according to what it receives .

As Ben  I also think this is a guidance , and I think it is good to bring s=
ome guidance.

Best regards

JJacques

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mardi 2 d=E9cembre 2014 19:50
=C0 : lionel.morand@orange.com; Ben Campbe=
ll
Cc : dime@ietf.org
Objet : Re: [Dime] Updates to DOIC -05

Lionel,

The two paragraphs together now say the following:

   When a reporting node sends an OLR, it effectively delegates any

   necessary throttling to downstream nodes.  If the reporting node also

   locally throttles the same set of messages, the overall number of

   throttled request may be higher than intended.  Therefore, if a

   reporting node needs to apply local throttling on a set of messages

   that match or overlap with existing OCS entries, it needs to consider

   the impact of throttling by downstream nodes.



   However, when the reporting node sends an OLR downstream, it might

   still need to apply other abatement methods such as diversion.  The

   reporting node might also need to throttle requests for reasons other

   than overload.  For example, an agent or server might have a

   configured rate limit for each client, and throttle requests that

   exceed that limit, even if such requests had already been candidates

   for throttling by downstream nodes.
Do you see the need for further clarification?

Steve
On 11/25/14, 12:26 PM, lionel.morand@orange.com wrote:

I'm OK with the idea of the text proposed by Ben.

I would just make clear that throttling is applicable to the fact of sendin=
g/forwarding requests (cf. definition). A reporting node may apply local th=
rottling if it is an agent. But if it is a server, it can either drop the e=
xceeded number of requests (no response sent to the downstream) or send a s=
pecific DIAMETER-TOO-BUSY response. I think that this clarification is some=
how missing in the document.



Regards,



Lionel



-----Message d'origine-----

De : Steve Donovan [mailto:srdonovan@usdonovans.com]

Envoy=E9 : mardi 25 novembre 2014 15:07

=C0 : Ben Campbell; MORAND Lionel IMT/OLN

Cc : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; =
Maria Cruz Bartolome

Objet : Re: [Dime] Updates to DOIC -05



I'm ok with Ben's wording and will make the change unless I hear objections=
 on the list.



Steve



On 11/21/14, 5:01 PM, Ben Campbell wrote:

On reflection, I think there might be a subtlety here. The resulting offere=
d-load may still exceed the reporting node's current capacity. This can be =
true even if it's sent an OLR (and thus has related OCS). As mentioned in t=
he surrounding node needs to still be able to protect itself, possibly by t=
hrottling. Therefore, I propose the sentence take the form of non-normative=
 guidance. For example:



"When a reporting node sends an OLR, it effectively delegates any necessary=
 throttling to downstream nodes.  If the reporting node also locally thrott=
les the same set of messages, the overall number of throttled request may b=
e higher than intended. Therefore, if a reporting node needs to apply local=
 throttling on a set of messages that match or overlap with existing OCS en=
tries, it needs to consider the impact of throttling by downstream nodes."





On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com wrote:



I can live with the text proposed by Ulrich. But what is wrong with:



" Therefore, the reporting node SHOULD NOT apply throttling to the set of m=
essages to which an active OCS applies." ?



Envoy=E9 depuis mon Sony Xperia SP d'Orange



---- Maria Cruz Bartolome a =E9crit ----





Section 4.2.3, 13th paragraph, 2nd sentence:

Existing text: Therefore, the reporting node SHOULD NOT apply throttling to=
 the set of messages to which the OLR applies.

Proposed text: Therefore, the reporting node SHOULD NOT apply throttling to=
 the set of messages to which the sent OLR applies.



[LM] I would say that the reporting node will not remember the previously s=
ent OLR, but will take care that there is an active OCS.

SRD> I'm ok with Ulrich's change.



[LM] and this is incorrect but not fundamental. The reporting node does not=
 have to "remember" a previously sent OLR. What it will do is to refer to e=
xisting OCS to know that throttling should not be applied. An OCS is a cons=
equence of an sent OLR but it is not an OLR itself. But not fundamental her=
e.



[MCruz] I am ok with Ulrich's change. It does not mean that the reporting n=
ode needs to "remember" a previously sent OLR, though. The change only prop=
oses to "identify" which OLR we refer to.



Best regards

/MCruz





_____________________________________________________________________

____________________________________________________



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 le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n, 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 dis=
tributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and dele=
te 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

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime







___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.







___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.


--_000_6B7134B31289DC4FAF731D844122B36E99DE18PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











I'm fine w=
ith the modified text.


 =
;


Lionel


 =
;






De :=
 Steve Donovan [mailto:srdonovan@usdonovans.co=
m]


Envoy=E9 : mercredi 3 d=E9cembre 2014 18:22

=C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); MORAND Lionel IMT/O=
LN; Ben Campbell

Cc : dime@ietf.org

Objet : Re: [Dime] Updates to DOIC -05






 


I have attempted to a=
ddress both Lionel's and Jean-Jacques' suggestions with the following text:=



   When a reporting node sends an OLR, it effectively delega=
tes any


   necessary throttling to downstream nodes.  If the re=
porting node also


   locally throttles the same set of messages, the overall n=
umber of


   throttled requests may be higher than intended.  The=
refore, before


   applying local message throttling, a reporting node needs=
 to check if


   these messages match existing OCS entries, indicating tha=
t these


   messages have survived throttling applied by downstream n=
odes that


   have received the related OLR.


 


   However, even if the set of messages match existing OCS e=
ntries, the


   reporting node can still apply other abatement methods su=
ch as


   diversion.  The reporting node might also need to th=
rottle requests


   for reasons other than overload.  For example, an ag=
ent or server


   might have a configured rate limit for each client, and t=
hrottle


   requests that exceed that limit, even if such requests ha=
d already


   been candidates for throttling by downstream nodes. =
 The reporting


   node also has the option to send new OLRs requesting grea=
ter


   reductions in traffic, reducing the need for local thrott=
ling.




Steve




On 12/3/14, 6:19 AM, TROTTIN, JEAN-JACQUES (JEAN-JAC=
QUES) wrote:






Dear all


 <=
/p>

To continue on my remark =
, I would complement the Steve’s text with “
can update the reduction of traffic it requires from the=
 reacting nodes(s) by sending new overload reports”
as hereafter:    


 


   Therefore, if a


   reporting node needs to apply local throttling on a set o=
f messages


   that match existing OCS entries, it needs to consider


   the impact of throttling by downstream nodes and can upda=
te the reduction of traffic it requires from the reacting nodes(s) by sendi=
ng new overload reports. 


 


Best regards<=
/o:p>


 <=
/p>

JJacques



 <=
/p>

 <=
/p>





De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Envoy=E9 : mercredi 3 d=E9cembre 2014 11:29

=C0 : Steve Donovan; lionel.morand@orange.com; Ben Campbell

Cc : dime@ietf.org

Objet : Re: [Dime] Updates to DOIC -05






 


Dear all


 <=
/p>

I am not against the new =
proposed texts from Steve or Ben to clarify this topic.

 <=
/p>

My point is that, when &n=
bsp;the reporting node has sent an OLR requiring  a traffic reduction =
, there is first a reaction time before receiving reduced traffic,
 and second even if the traffic has been reduced, it can still exceed the c=
apacity of the reporting node  that has no other choice than to thrott=
le the received reduced traffic (if no diversion). This can happen when the=
 traffic at the source (reacting node)
 before throttling is increasing quickly, so the traffic reduced  acco=
rding to the received OLR may  remain too high .  Then, if the re=
porting node has nevertheless to do some throttle, it will certainly react =
by new OLRs requiring a higher traffic reduction
 from the reacting nodes. This is a dynamic process, where the reporting no=
de adjust the  traffic  reduction it requires according to what i=
t receives .


 <=
/p>

As Ben  I also think=
 this is a guidance , and I think it is good to bring some guidance.



 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques



 <=
/p>





De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mardi 2 d=E9cembre 2014 19:50

=C0 : lionel.morand=
@orange.com; Ben Campbell

Cc : dime@ietf.org

Objet : Re: [Dime] Updates to DOIC -05






 


Lionel,



The two paragraphs together now say the following:


   When a reporting node sends an OLR, it effectively delega=
tes any


   necessary throttling to downstream nodes.  If the re=
porting node also


   locally throttles the same set of messages, the overall n=
umber of


   throttled request may be higher than intended.  Ther=
efore, if a


   reporting node needs to apply local throttling on a set o=
f messages


   that match or overlap with existing OCS entries, it needs=
 to consider


   the impact of throttling by downstream nodes.<=
/pre>

 


   However, when the reporting node sends an OLR downstream,=
 it might


   still need to apply other abatement methods such as diver=
sion.  The


   reporting node might also need to throttle requests for r=
easons other


   than overload.  For example, an agent or server migh=
t have a


   configured rate limit for each client, and throttle reque=
sts that


   exceed that limit, even if such requests had already been=
 candidates


   for throttling by downstream nodes.


Do you see the need f=
or further clarification?



Steve




On 11/25/14, 12:26 PM, 
lionel.morand@orange.com wrote:






I'm OK with the idea of the text proposed by Ben.


I would just make clear that throttling is applicable to the fact of s=
ending/forwarding requests (cf. definition). A reporting node may apply loc=
al throttling if it is an agent. But if it is a server, it can either drop =
the exceeded number of requests (no response sent to the downstream) or sen=
d a specific DIAMETER-TOO-BUSY response. I think that this clarification is=
 somehow missing in the document.


 


Regards,


 


Lionel


 


-----Message d'origine-----


De : Steve Donovan [m=
ailto:srdonovan@usdonovans.com] 


Envoy=E9 : mardi 25 novembre 2014 15:07


=C0 : Ben Campbell; MORAND Lionel IMT/OLN


Cc : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; Maria Cruz Bartolome


Objet : Re: [Dime] Updates to DOIC -05


 


I'm ok with Ben's wording and will make the change unless I hear objec=
tions on the list.


 


Steve


 


On 11/21/14, 5:01 PM, Ben Campbell wrote:




On reflection, I think there might be a subtlety here. The resulting o=
ffered-load may still exceed the reporting node's current capacity. This ca=
n be true even if it's sent an OLR (and thus has related OCS). As mentioned=
 in the surrounding node needs to still be able to protect itself, possibly=
 by throttling. Therefore, I propose the sentence take the form of non-norm=
ative guidance. For example:


 


"When a reporting node sends an OLR, it effectively delegates any=
 necessary throttling to downstream nodes.  If the reporting node also=
 locally throttles the same set of messages, the overall number of throttle=
d request may be higher than intended. Therefore, if a reporting node needs=
 to apply local throttling on a set of messages that match or overlap with =
existing OCS entries, it needs to consider the impact of throttling by down=
stream nodes."


 


  




On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com wrote:


 


I can live with the text proposed by Ulrich. But what is wrong with:


 


" Therefore, the reporting node SHOULD NOT apply throttling to th=
e set of messages to which an active OCS applies." ?


 


Envoy=E9 depuis mon Sony Xperia SP d'Orange


 


---- Maria Cruz Bartolome a =E9crit ----


 


 




Section 4.2.3, 13th paragraph, 2nd sentence:


Existing text: Therefore, the reporting node SHOULD NOT apply throttli=
ng to the set of messages to which the OLR applies.


Proposed text: Therefore, the reporting node SHOULD NOT apply throttli=
ng to the set of messages to which the sent OLR applies.


 


[LM] I would say that the reporting node will not remember the previou=
sly sent OLR, but will take care that there is an active OCS.



SRD> I'm ok with Ulrich's change.


 


[LM] and this is incorrect but not fundamental. The reporting node doe=
s not have to "remember" a previously sent OLR. What it will do i=
s to refer to existing OCS to know that throttling should not be applied. A=
n OCS is a consequence of an sent OLR but it is not an OLR itself. But not =
fundamental here.


 


[MCruz] I am ok with Ulrich's change. It does not mean that the report=
ing node needs to "remember" a previously sent OLR, though. The c=
hange only proposes to "identify" which OLR we refer to.


 


Best regards


/MCruz


 


 


_____________________________________________________________________<=
o:p>


____________________________________________________


 


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 q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration, Orange decline toute responsabilite si ce message a ete altere, def=
orme ou falsifie. Merci.


 


This message and its attachments may contain confidential or 


privileged information that may be protected by law; they should not b=
e 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


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.


 


 




 




 




______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.




--_000_6B7134B31289DC4FAF731D844122B36E99DE18PEXCVZYM13corpora_--


From nobody Wed Dec  3 12:38:57 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB3A1A6F3A; Wed,  3 Dec 2014 12:38:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSm98bGQ3HSH; Wed,  3 Dec 2014 12:38:52 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC6A1A1E0E; Wed,  3 Dec 2014 12:38:52 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141203203852.21756.15977.idtracker@ietfa.amsl.com>
Date: Wed, 03 Dec 2014 12:38:52 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/eUq7ZhH5B19cyg9QtMz3qP-u_2o
Cc: dime@ietf.org
Subject: [Dime] I-D Action: draft-ietf-dime-ovli-05.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Dec 2014 20:38:54 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF.

        Title           : Diameter Overload Indication Conveyance
        Authors         : Jouni Korhonen
                          Steve Donovan
                          Ben Campbell
                          Lionel Morand
	Filename        : draft-ietf-dime-ovli-05.txt
	Pages           : 52
	Date            : 2014-12-03

Abstract:
   This specification defines a base solution for Diameter overload
   control, referred to as Diameter Overload Indication Conveyance
   (DOIC).

Requirements

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dime-ovli-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Dec  3 14:32:01 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3B91ACE02 for ; Wed,  3 Dec 2014 14:31:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xg7O8CirG_ip for ; Wed,  3 Dec 2014 14:31:55 -0800 (PST)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF34D1ACE18 for ; Wed,  3 Dec 2014 14:31:40 -0800 (PST)
Received: by mail-lb0-f179.google.com with SMTP id z11so12880500lbi.24 for ; Wed, 03 Dec 2014 14:31:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=4/QnMG9I4V1PxYZDqoc6OMOYDY9LD8ERBWNXXaezi2A=; b=IQrvPymj04COk/SCihcfdUINgxzSyRdvCg7UvXvF63Vm59xa0qiJlEcc5uUZEBDiWW G//8Ia98+MscJyNBDPdDvp6XgnCq39JG74CaRRhJk1dbUAz5JqcsGUe+vcLPZDWDmS85 DzohQuFmWGShOs+bPVx9KrClu7AwQ6a8o6Rx8wHQ9xKTd2es0sm4P6Sbq4Bubf0LFX/7 cy4gJIIvApqgnWO5v3DsAXaaYD3eRXI/sb7bw3jZOiVxXytC4FizSmYhMYt56BsBJgqk vOK661NcuivkXsuujGxMFDNmi+Mn9QrPQWuHXStVOJzdmMEzKuZAV8/5dj5gzKs8F5il SGJw==
X-Received: by 10.152.115.172 with SMTP id jp12mr6311849lab.33.1417645899279;  Wed, 03 Dec 2014 14:31:39 -0800 (PST)
Received: from [10.17.0.23] ([83.150.126.201]) by mx.google.com with ESMTPSA id ei11sm6710180lad.18.2014.12.03.14.31.37 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 14:31:38 -0800 (PST)
Message-ID: <547F8F43.1010705@gmail.com>
Date: Thu, 04 Dec 2014 00:31:31 +0200
From: Jouni Korhonen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/YlRGwh1yE-npg61xPO-nW2gJ1Dw
Subject: [Dime] WLGC #1 for draft-ietf-dime-ovli-05
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Dec 2014 22:31:57 -0000

Folks,

We have had a considerable update on the DOIC draft based on the 
comments from the interim meeting, Honolulu meeting and discussions held 
lately on the mailinglist. Authors/chairs think the -05 draft is now 
ready for a WGLC and the rest of the potential comments can be handled 
as WGLC comments.

This email starts a two week WGLC #1 for draft-ietf-dime-ovli-05. The 
WGLC ends 18th Dec 2014 EOB (CET+1). Post your review comments and 
concerns to the mailinglist. Also make use of the issue tracker 
(remember to select "severity" as "in WG last call").

Lionel & Jouni


From nobody Wed Dec  3 23:09:18 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FCE1A88DD for ; Wed,  3 Dec 2014 23:09:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level: 
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qFQ-i7jvZlH for ; Wed,  3 Dec 2014 23:09:06 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763161A88E1 for ; Wed,  3 Dec 2014 23:09:05 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 9D0FAAF2C9C59; Thu,  4 Dec 2014 07:09:01 +0000 (GMT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sB4791DK016687 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Dec 2014 08:09:01 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.50]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 08:09:01 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "lionel.morand@orange.com" , Steve Donovan , Ben Campbell 
Thread-Topic: [Dime] Updates to DOIC -05
Thread-Index: AQHP96zWh2IhAI9MNUyrs2P7h3In05xXdZWAgAKB9QCAABTjgIABToGAgABXjYCAAImqAIAAtOqAgAHz+gCAAFg3AIAFNTcAgAARHgCABzpwAIAFs+cAgABIhYCACwbhAIABEZ9ggAAii9CAAEXUgIAAB5YAgADv6OA=
Date: Thu, 4 Dec 2014 07:09:00 +0000
Message-ID: 
References: <545792B6.8030502@usdonovans.com> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, > <087A34937E64E74E848732CFF8354B9209863A54@ESESSMB101.ericsson.se> <24987_1416213505_5469B401_24987_4151_1_judb1lo2cnj5m4v6mdt5aec1.1416213483721@email.android.com>  <54748CEA.3020705@usdonovans.com> <19072_1416939968_5474C9C0_19072_1519_1_6B7134B31289DC4FAF731D844122B36E941639@PEXCVZYM13.corporate.adroot.infra.ftgroup> <547E09C0.5080305@usdonovans.com>   <547F46D5.7060800@usdonovans.com> <19906_1417628979_547F4D33_19906_1955_1_6B7134B31289DC4FAF731D844122B36E99DE18@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <19906_1417628979_547F4D33_19906_1955_1_6B7134B31289DC4FAF731D844122B36E99DE18@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D2026F1197FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/zlPuOB6BBmKlobl-R7zS1ouSfG4
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Updates to DOIC -05
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Dec 2014 07:09:14 -0000

--_000_E194C2E18676714DACA9C3A2516265D2026F1197FR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Steve's text  is also fine for me.

Best regards

JJacques

De : lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Envoy=E9 : mercredi 3 d=E9cembre 2014 18:50
=C0 : Steve Donovan; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Ben Campbell
Cc : dime@ietf.org
Objet : RE: [Dime] Updates to DOIC -05

I'm fine with the modified text.

Lionel

De : Steve Donovan [mailto:srdonovan@usdonovans.com]
Envoy=E9 : mercredi 3 d=E9cembre 2014 18:22
=C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); MORAND Lionel IMT/OLN; Ben Camp=
bell
Cc : dime@ietf.org
Objet : Re: [Dime] Updates to DOIC -05

I have attempted to address both Lionel's and Jean-Jacques' suggestions wit=
h the following text:

   When a reporting node sends an OLR, it effectively delegates any

   necessary throttling to downstream nodes.  If the reporting node also

   locally throttles the same set of messages, the overall number of

   throttled requests may be higher than intended.  Therefore, before

   applying local message throttling, a reporting node needs to check if

   these messages match existing OCS entries, indicating that these

   messages have survived throttling applied by downstream nodes that

   have received the related OLR.



   However, even if the set of messages match existing OCS entries, the

   reporting node can still apply other abatement methods such as

   diversion.  The reporting node might also need to throttle requests

   for reasons other than overload.  For example, an agent or server

   might have a configured rate limit for each client, and throttle

   requests that exceed that limit, even if such requests had already

   been candidates for throttling by downstream nodes.  The reporting

   node also has the option to send new OLRs requesting greater

   reductions in traffic, reducing the need for local throttling.

Steve
On 12/3/14, 6:19 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
Dear all

To continue on my remark , I would complement the Steve's text with " can u=
pdate the reduction of traffic it requires from the reacting nodes(s) by se=
nding new overload reports" as hereafter:



   Therefore, if a

   reporting node needs to apply local throttling on a set of messages

   that match existing OCS entries, it needs to consider

   the impact of throttling by downstream nodes and can update the reductio=
n of traffic it requires from the reacting nodes(s) by sending new overload=
 reports.


Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Envoy=E9 : mercredi 3 d=E9cembre 2014 11:29
=C0 : Steve Donovan; lionel.morand@orange.com; Ben Campbell
Cc : dime@ietf.org
Objet : Re: [Dime] Updates to DOIC -05

Dear all

I am not against the new proposed texts from Steve or Ben to clarify this t=
opic.

My point is that, when  the reporting node has sent an OLR requiring  a tra=
ffic reduction , there is first a reaction time before receiving reduced tr=
affic, and second even if the traffic has been reduced, it can still exceed=
 the capacity of the reporting node  that has no other choice than to throt=
tle the received reduced traffic (if no diversion). This can happen when th=
e traffic at the source (reacting node) before throttling is increasing qui=
ckly, so the traffic reduced  according to the received OLR may  remain too=
 high .  Then, if the reporting node has nevertheless to do some throttle, =
it will certainly react by new OLRs requiring a higher traffic reduction fr=
om the reacting nodes. This is a dynamic process, where the reporting node =
adjust the  traffic  reduction it requires according to what it receives .

As Ben  I also think this is a guidance , and I think it is good to bring s=
ome guidance.

Best regards

JJacques

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mardi 2 d=E9cembre 2014 19:50
=C0 : lionel.morand@orange.com; Ben Campbe=
ll
Cc : dime@ietf.org
Objet : Re: [Dime] Updates to DOIC -05

Lionel,

The two paragraphs together now say the following:

   When a reporting node sends an OLR, it effectively delegates any

   necessary throttling to downstream nodes.  If the reporting node also

   locally throttles the same set of messages, the overall number of

   throttled request may be higher than intended.  Therefore, if a

   reporting node needs to apply local throttling on a set of messages

   that match or overlap with existing OCS entries, it needs to consider

   the impact of throttling by downstream nodes.



   However, when the reporting node sends an OLR downstream, it might

   still need to apply other abatement methods such as diversion.  The

   reporting node might also need to throttle requests for reasons other

   than overload.  For example, an agent or server might have a

   configured rate limit for each client, and throttle requests that

   exceed that limit, even if such requests had already been candidates

   for throttling by downstream nodes.
Do you see the need for further clarification?

Steve
On 11/25/14, 12:26 PM, lionel.morand@orange.com wrote:

I'm OK with the idea of the text proposed by Ben.

I would just make clear that throttling is applicable to the fact of sendin=
g/forwarding requests (cf. definition). A reporting node may apply local th=
rottling if it is an agent. But if it is a server, it can either drop the e=
xceeded number of requests (no response sent to the downstream) or send a s=
pecific DIAMETER-TOO-BUSY response. I think that this clarification is some=
how missing in the document.



Regards,



Lionel



-----Message d'origine-----

De : Steve Donovan [mailto:srdonovan@usdonovans.com]

Envoy=E9 : mardi 25 novembre 2014 15:07

=C0 : Ben Campbell; MORAND Lionel IMT/OLN

Cc : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; =
Maria Cruz Bartolome

Objet : Re: [Dime] Updates to DOIC -05



I'm ok with Ben's wording and will make the change unless I hear objections=
 on the list.



Steve



On 11/21/14, 5:01 PM, Ben Campbell wrote:

On reflection, I think there might be a subtlety here. The resulting offere=
d-load may still exceed the reporting node's current capacity. This can be =
true even if it's sent an OLR (and thus has related OCS). As mentioned in t=
he surrounding node needs to still be able to protect itself, possibly by t=
hrottling. Therefore, I propose the sentence take the form of non-normative=
 guidance. For example:



"When a reporting node sends an OLR, it effectively delegates any necessary=
 throttling to downstream nodes.  If the reporting node also locally thrott=
les the same set of messages, the overall number of throttled request may b=
e higher than intended. Therefore, if a reporting node needs to apply local=
 throttling on a set of messages that match or overlap with existing OCS en=
tries, it needs to consider the impact of throttling by downstream nodes."





On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com wrote:



I can live with the text proposed by Ulrich. But what is wrong with:



" Therefore, the reporting node SHOULD NOT apply throttling to the set of m=
essages to which an active OCS applies." ?



Envoy=E9 depuis mon Sony Xperia SP d'Orange



---- Maria Cruz Bartolome a =E9crit ----





Section 4.2.3, 13th paragraph, 2nd sentence:

Existing text: Therefore, the reporting node SHOULD NOT apply throttling to=
 the set of messages to which the OLR applies.

Proposed text: Therefore, the reporting node SHOULD NOT apply throttling to=
 the set of messages to which the sent OLR applies.



[LM] I would say that the reporting node will not remember the previously s=
ent OLR, but will take care that there is an active OCS.

SRD> I'm ok with Ulrich's change.



[LM] and this is incorrect but not fundamental. The reporting node does not=
 have to "remember" a previously sent OLR. What it will do is to refer to e=
xisting OCS to know that throttling should not be applied. An OCS is a cons=
equence of an sent OLR but it is not an OLR itself. But not fundamental her=
e.



[MCruz] I am ok with Ulrich's change. It does not mean that the reporting n=
ode needs to "remember" a previously sent OLR, though. The change only prop=
oses to "identify" which OLR we refer to.



Best regards

/MCruz





_____________________________________________________________________

____________________________________________________



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 le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n, 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 dis=
tributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and dele=
te 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

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime







___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.







___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.

--_000_E194C2E18676714DACA9C3A2516265D2026F1197FR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Steve’s text  =
is also fine for me.


 <=
/p>

Best regards


 <=
/p>

JJacques


 <=
/p>





De =
: lionel.morand@orange.=
com [mailto:lionel.morand@orange.com]


Envoy=E9 : mercredi 3 d=E9cembre 2014 18:50

=C0 : Steve Donovan; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Ben =
Campbell

Cc : dime@ietf.org

Objet : RE: [Dime] Updates to DOIC -05






 


I'm fine with the modifie=
d text.


 


Lionel


 






De =
: Steve Donovan [mailto:srdonovan@usdonovans.com]


Envoy=E9 : mercredi 3 d=E9cembre 2014 18:22

=C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); MORAND Lionel IMT/O=
LN; Ben Campbell

Cc : dime@ietf.org

Objet : Re: [Dime] Updates to DOIC -05=







 


I h=
ave attempted to address both Lionel's and Jean-Jacques' suggestions with t=
he following text:


   When a reporting node sends an OLR, it =
effectively delegates any


   necessary throttling to downstream node=
s.  If the reporting node also


   locally throttles the same set of messa=
ges, the overall number of


   throttled requests may be higher than i=
ntended.  Therefore, before


   applying local message throttling, a re=
porting node needs to check if


   these messages match existing OCS entri=
es, indicating that these


   messages have survived throttling appli=
ed by downstream nodes that


   have received the related OLR.


 


   However, even if the set of messages ma=
tch existing OCS entries, the


   reporting node can still apply other ab=
atement methods such as


   diversion.  The reporting node mig=
ht also need to throttle requests


   for reasons other than overload.  =
For example, an agent or server


   might have a configured rate limit for =
each client, and throttle


   requests that exceed that limit, even i=
f such requests had already


   been candidates for throttling by downs=
tream nodes.  The reporting


   node also has the option to send new OL=
Rs requesting greater


   reductions in traffic, reducing the nee=
d for local throttling.



Steve




On 12/3/14, 6:19 AM, TROTTIN, JEAN=
-JACQUES (JEAN-JACQUES) wrote:






Dear all


 =



To continue o=
n my remark , I would complement the Steve’s text with “
can update the reduction of traffic it requi=
res from the reacting nodes(s) by sending new overload reports”
as hereafter:   &nb=
sp;


 


   Therefore, if a


   reporting node needs to apply local thr=
ottling on a set of messages


   that match existing OCS entries, it nee=
ds to consider


   the impact of throttling by downstream =
nodes and can update the reduction of traffic it requires from the reacting=
 nodes(s) by sending new overload reports. 


 


Best regards<=
/span>


 =



JJacques



 =



 =







De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Envoy=E9 : mercredi 3 d=E9cembre 2014 11:29

=C0 : Steve Donovan; lionel.morand@orange.com; Ben Campbell

Cc : dime@ietf.org

Objet : Re: [Dime] Updates to DOIC -05=







 


Dear all


 =



I am not agai=
nst the new proposed texts from Steve or Ben to clarify this topic.<=
span lang=3D"FR">


 =



My point is t=
hat, when  the reporting node has sent an OLR requiring  a traffi=
c reduction , there is first a reaction time before receiving reduced
 traffic, and second even if the traffic has been reduced, it can still exc=
eed the capacity of the reporting node  that has no other choice than =
to throttle the received reduced traffic (if no diversion). This can happen=
 when the traffic at the source (reacting
 node) before throttling is increasing quickly, so the traffic reduced =
; according to the received OLR may  remain too high .  Then, if =
the reporting node has nevertheless to do some throttle, it will certainly =
react by new OLRs requiring a higher traffic reduction
 from the reacting nodes. This is a dynamic process, where the reporting no=
de adjust the  traffic  reduction it requires according to what i=
t receives .


 =



As Ben  =
I also think this is a guidance , and I think it is good to bring some guid=
ance.



 =



Best regards<=
/span>


 =



JJacques



 =







De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mardi 2 d=E9cembre 2014 19:50

=C0 : lionel.morand=
@orange.com; Ben Campbell

Cc : dime@ietf.org

Objet : Re: [Dime] Updates to DOIC -05=







 


Lio=
nel,



The two paragraphs together now say the following:


   When a reporting node sends an OLR, it =
effectively delegates any


   necessary throttling to downstream node=
s.  If the reporting node also


   locally throttles the same set of messa=
ges, the overall number of


   throttled request may be higher than in=
tended.  Therefore, if a


   reporting node needs to apply local thr=
ottling on a set of messages


   that match or overlap with existing OCS=
 entries, it needs to consider


   the impact of throttling by downstream =
nodes.


 


   However, when the reporting node sends =
an OLR downstream, it might


   still need to apply other abatement met=
hods such as diversion.  The


   reporting node might also need to throt=
tle requests for reasons other


   than overload.  For example, an ag=
ent or server might have a


   configured rate limit for each client, =
and throttle requests that


   exceed that limit, even if such request=
s had already been candidates


   for throttling by downstream nodes.


Do =
you see the need for further clarification?



Steve




On 11/25/14, 12:26 PM, 
lionel.morand@orange.com wrote:






I'm OK with the idea of the text proposed by Ben.


I would just make clear that throttling is applicabl=
e to the fact of sending/forwarding requests (cf. definition). A reporting =
node may apply local throttling if it is an agent. But if it is a server, i=
t can either drop the exceeded number of requests (no response sent to the =
downstream) or send a specific DIAMETER-TOO-BUSY response. I think that thi=
s clarification is somehow missing in the document.


 


Regards,


 


Lionel


 


-----Message d'origine-----


De : Steve Donovan [mailto:srdonovan@usdonovans.com] 

Envoy=E9 : mardi 25 novembre 2014 15:07


=C0 : Ben Campbell; MORAND Lionel IMT/OLN<=
/o:p>


Cc : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; Maria Cruz Bartolome


Objet : Re: [Dime] Updates to DOIC -05


 


I'm ok with Ben's wording and will make the change u=
nless I hear objections on the list.


 


Steve


 


On 11/21/14, 5:01 PM, Ben Campbell wrote:=





On reflection, I think there might be a subtlety her=
e. The resulting offered-load may still exceed the reporting node's current=
 capacity. This can be true even if it's sent an OLR (and thus has related =
OCS). As mentioned in the surrounding node needs to still be able to protec=
t itself, possibly by throttling. Therefore, I propose the sentence take th=
e form of non-normative guidance. For example:


 


"When a reporting node sends an OLR, it effecti=
vely delegates any necessary throttling to downstream nodes.  If the r=
eporting node also locally throttles the same set of messages, the overall =
number of throttled request may be higher than intended. Therefore, if a re=
porting node needs to apply local throttling on a set of messages that matc=
h or overlap with existing OCS entries, it needs to consider the impact of =
throttling by downstream nodes."


 


  




On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com wrote:<=
/pre>

 


I can live with the text proposed by Ulrich. But wha=
t is wrong with:


 


" Therefore, the reporting node SHOULD NOT appl=
y throttling to the set of messages to which an active OCS applies." ?=



 


Envoy=E9 depuis mon Sony Xperia SP d'Orange


 


---- Maria Cruz Bartolome a =E9crit ----<=
/span>


 


 




Section 4.2.3, 13th paragraph, 2nd sentence:


Existing text: Therefore, the reporting node SHOULD =
NOT apply throttling to the set of messages to which the OLR applies.<=
/o:p>


Proposed text: Therefore, the reporting node SHOULD =
NOT apply throttling to the set of messages to which the sent OLR applies.<=
o:p>


 


[LM] I would say that the reporting node will not re=
member the previously sent OLR, but will take care that there is an active =
OCS.




SRD> I'm ok with Ulrich's change.


 


[LM] and this is incorrect but not fundamental. The =
reporting node does not have to "remember" a previously sent OLR.=
 What it will do is to refer to existing OCS to know that throttling should=
 not be applied. An OCS is a consequence of an sent OLR but it is not an OL=
R itself. But not fundamental here.


 


[MCruz] I am ok with Ulrich's change. It does not me=
an that the reporting node needs to "remember" a previously sent =
OLR, though. The change only proposes to "identify" which OLR we =
refer to.


 


Best regards


/MCruz


 


 


____________________________________________________=
_________________


____________________________________________________=



 


Ce message et ses pieces jointes peuvent contenir de=
s informations 


confidentielles ou privilegiees et ne doivent donc p=
as etre diffuses, 


exploites ou copies sans autorisation. Si vous avez =
recu ce message 


par erreur, veuillez le signaler a l'expediteur et l=
e detruire ainsi que les pieces jointes. Les messages electroniques etant s=
usceptibles d'alteration, Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confide=
ntial 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 not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


 


_______________________________________________=



DiME mailing list


DiME@ietf.org


https://www.ietf.org/mailman/listinfo/dime




 




 


 


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


 


 




 




 


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.






--_000_E194C2E18676714DACA9C3A2516265D2026F1197FR712WXCHMBA12z_--


From nobody Mon Dec  8 02:06:23 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4C11A89E9 for ; Mon,  8 Dec 2014 02:06:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.901
X-Spam-Level: 
X-Spam-Status: No, score=-8.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cx-jyxLKDvlU for ; Mon,  8 Dec 2014 02:06:16 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F411A89F5 for ; Mon,  8 Dec 2014 02:06:15 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sB8A6C8g000730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Dec 2014 10:06:12 GMT
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sB8A6Bbp027265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Dec 2014 11:06:11 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 11:06:11 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Jouni Korhonen , "dime@ietf.org" 
Thread-Topic: [Dime] WLGC #1 for draft-ietf-dime-ovli-05
Thread-Index: AQHQD0j2TUdPtbiANUulpB3cTV/mopyBBToA
Date: Mon, 8 Dec 2014 10:06:11 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815232D29@DEMUMBX014.nsn-intra.net>
References: <547F8F43.1010705@gmail.com>
In-Reply-To: <547F8F43.1010705@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 23516
X-purgate-ID: 151667::1418033172-0000658F-582F72EB/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/nAJg4AiHU0nRhOgfauK5_JLqmpM
Subject: Re: [Dime] WLGC #1 for draft-ietf-dime-ovli-05
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Dec 2014 10:06:21 -0000

Dear Lionel & Jouni,

here are my review comments.=20
I think those are all not contentious.
Best regards
Ulrich

Section 3, last paragraph:
Existing text:
   While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
   that are "adjacent" for DOIC purposes may not be adjacent from a
   Diameter, or transport, perspective.  For example, one or more
   Diameter agents that do not support DOIC may exist between a given
   pair of reporting and reacting nodes, as long as those agents pass
   unknown AVPs through unchanged.  The report types described in this
   document can safely pass through non-supporting agents.  This may not
   be true for report types defined in future specifications.
Comment: while this is all not wrong, the existing text may convey the erri=
ng impression that there cannot be a DOIC supporting agent on the path betw=
een a reporting node and an adjacent reacting node.=20
Proposal: It is proposed to add the following sentence at the end of the pa=
ragraph:
   Another example is where one or more Diameter agents that do support
   DOIC may exist between a given pair of reporting and reacting nodes,
   as long as those agents pass OC-specific AVPs through unchanged.

Section 3.2, 6th paragraph:
Existing text:
   The OC-Feature-Vector AVP will contain an indication of support for
   the loss overload abatement algorithm defined in this specification
   (see Section 5).  This ensures that there is at least one commonly
   supported overload abatement algorithm between the reporting node and
   the reacting node(s) in the path of the request.
Comment: I agree that within a given path between client and server there m=
ay be more than one reacting nodes. But a given reporting node on that path=
 does not have more than one adjacent reacting nodes on that given path to =
which it sends OLRs. I don't say that the existing text is wrong, but it is=
 misleading. What we want to say here is that any given pair of adjacent re=
acting and reporting nodes will have at least one commonly supported algori=
thm.
Proposal: It is proposed to replace the last line of the paragraph with:
   The adjacent reacting node on the path of the request.

Section 3.2, last two paragraphs:
Existing text:
   The DCA mechanism must also allow the scenario where the set of
   features supported by the sender of a request and by agents in the
   path of a request differ.  In this case, the agent updates the OC-
   Supported-Features AVP to reflect the mixture of the two sets of
   supported features.

      Note: The logic to determine the content of the modified  OC-
      Supported-Features AVP is out-of-scope for this specification and
      is left to implementation decisions.  Care must be taken not to
      introduce interoperability issues for downstream or upstream DOIC
      nodes.
Comment: It is perfectly ok (in this case) for the agent not to update and =
not to modify.=20
Proposal: It is proposed to replace the two paragraphs with the following:
   The DCA mechanism must also allow the scenario where the set of
   features supported by the sender of a request and by agents in the
   path of a request differ.  In this case, the agent can update the OC-
   Supported-Features AVP to reflect the mixture of the two sets of
   supported features.

      Note: The logic to determine whether and if how to modify the
      content of the OC-Supported-Features AVP is out-of-scope for this
      specification and is left to implementation decisions.  Care must
      be taken not to introduce interoperability issues for downstream
      or upstream DOIC nodes.

Section 3.3, 4th and 5th paragraph:
Existing text:
   A report of type "HOST_REPORT" is sent to indicate the overload of a
   specific Diameter node for the application-id indicated in the
   transaction.  When receiving an OLR of type host, a reacting node
   applies overload abatement to what is referred to in this document as
   host-routed requests.  The reacting node applies overload abatement
   on those host-routed requests which the reacting node knows will be
   served by the server that matches the Origin-Host AVP of the received
   message that contained the received OLR of type host.

   A report of type "REALM_REPORT" applies to realm-routed requests for
   a specific realm as indicated in the Destination-Realm AVP.
Comment: While the 4th paragraph is all fine, the 5th paragraph should be a=
ligned.
Proposal: It is proposed to replace the 5th paragraph with:
   A report of type "REALM_REPORT" is sent to indicate the overload of all
   Diameter nodes within a realm for the application-id indicated in the
   transaction.  When receiving an OLR of type realm, a reacting node
   applies overload abatement to what is referred to in this document as
   realm-routed requests.  The reacting node applies overload abatement
   on those realm-routed requests which contain  a Destination-Realm AVP
   that matches the Origin-Realm AVP of the received message that
   contained the received OLR of type realm.

Section 3.3, 8th paragraph:
Existing text:
   Reporting nodes are responsible for determining the need for a
   reduction of traffic.  The method for making this determination is
   implementation specific and depend on the type of overload report
   being generated.  A host-report, for instance, will generally be
   generated by tracking utilization of resources required by the host
   to handle transactions for the Diameter application.  A realm-report
   generally impacts the traffic sent to multiple hosts and, as such,
   requires tracking the capacity all servers for realm-routed requests
   for the application and realm.
Comment: Something is wrong with the last sentence.
Proposal: Replace the last sentence with:
                                                         A realm-report
   generally impacts the traffic sent to multiple hosts and, as such,
   requires tracking the capacity of all servers able to handle realm-
   routed requests for the application and realm.

Section 3.3, 12th paragraph:
Existing text:
   As the conditions that lead to the generation of the overload report
   change the reporting node can send new overload reports requesting
   greater reduction if the condition gets worse or less reduction if
   the condition improves.  The reporting node sends an overload report
   with a duration of zero to indicate that the overload condition has
   ended and need for use of the abatement algorithm to reduce traffic
   sent is no longer needed.
Comment: Bad style.
Proposal: Remove the words "need for" from the last sentence.

Section 4.1.2, 4th paragraph:
Existing text:
   A reporting node knows what overload control functionality is
   supported by the reacting node based on the content of the OC-
   Feature-Vector AVP in the request message.
Comment: The Feature-Vector AVP may be absent. In this case knowledge canno=
t be based on the content.
Proposal: Replace the paragraph with:
   A reporting node knows what overload control functionality is
   supported by the reacting node based on the content or absence of
   the OC-Feature-Vector AVP within the Supported-Features AVP in the
   request message.

Section 4.1.2, 8th paragraph:
Existing text:
   For an ongoing overload condition, a reporting node MUST NOT change
   the selected algorithm during the period of time that it is in an
   overload condition and, as a result, is sending OC-OLR AVPs in answer
   messages.
Comment: As a result of an ongoing overload condition the reporting node is=
 sending OC-OLR AVPs containing no validity duration or a validity duration=
 different from zero in answer messages.
Proposal: Replace the paragraph with:
   For an ongoing overload condition, a reporting node MUST NOT change
   the selected algorithm during the period of time that it is in an
   overload condition and, as a result, is sending OC-OLR AVPs
   containing no validity duration or a validity duration different
   from zero in answer messages.

Section 4.1.3, 1st paragraph:
Existing text:
   Diameter Agents that support DOIC SHOULD ensure that all messages
   relayed by the agent contain the OC-Supported-Features AVP.
Comment: The SHOULD in the first line is not correct based on my next comme=
nt.
Proposal: Delete the first paragraph.=20

Section 4.1.3, 4th paragraph:
Existing text:
   A Diameter Agent SHOULD take on reporting node behavior for Diameter
   endpoints that do not support the DOIC solution.  A Diameter Agent
   detects that a Diameter endpoint does not support DOIC reporting node
   behavior when there is no OC-Supported-Features AVP in an answer
   message for a transaction that contained the OC-Supported-Features
   AVP in the request message.
Comment: The first sentence can reasonably only apply to Diameter agents th=
at are immediate peers to the non-supporting Diameter endpoint. We cannot e=
xpect a far-away-agent to take on reporting node behavior when all upstream=
 agents and the server do not support DOIC. Furthermore: When the non-suppo=
rting server has two DOIC supporting immediate peer agents which both take =
on reporting node behavior we end up in problems similar to those identifie=
d in the note in section 3.3.
Proposal:Replace the paragaph with:
   A Diameter Agent that is an immediate peer to the Diameter endpoint
   that does not support DOIC SHOULD take on reporting node behavior for
   Diameter endpoints that do not support the DOIC solution.  A Diameter
   Agent detects that a Diameter endpoint does not support DOIC reporting
   node behavior when there is no OC-Supported-Features AVP in an answer
   message for a transaction that contained the OC-Supported-Features
   AVP in the request message.
      Note: Known issues exist if multiple sources for overload reports
      which apply to the same Diameter entity exist.  Reacting nodes
      have no way of determining the source and, as such, will treat
      them as coming from a single source.  Variance in sequence numbers
      between the two sources can then cause incorrect overload
      abatement treatment to be applied for indeterminate periods of
      time.
=20
Section 4.1.3, 6th paragraph:
Existing text:
   As with a Diameter endpoint taking on reporting node behavior, a
   Diameter Agent MUST only include the OC-Supported-Features AVP in
   answer messages for transactions where the request message received
   by the Diameter Agent had an OC-Supported-Features AVP.
Comments: "MUST only do x for condition y" could mean:
a) "MUST do x for condition y and MUST NOT do x for conditions other than y=
", or
b) "MUST do x and nothing else for condition y, and nothing is specified fo=
r conditions other than y".
Proposal: Replace the paragraph with:
   As with a Diameter endpoint taking on reporting node behavior, a
   Diameter Agent MUST NOT include the OC-Supported-Features AVP in
   answer messages for transactions where the request message received
   by the Diameter Agent had no OC-Supported-Features AVP.

Section 4.1.3, last paragraph:
Existing text:
   When making changes to the OC-Supported-Features AVP the Diameter
   Agent needs to ensure that there is no ambiguity in DOIC behavior for
   both upstream and downstream DOIC nodes.
Comment: while that is true, in addition problems similar to those identifi=
ed in the note in section 3.3 may result from making changes.
Proposal: Add the note:
      Note: Known issues exist if multiple sources for overload reports
      which apply to the same Diameter entity exist.  Reacting nodes
      have no way of determining the source and, as such, will treat
      them as coming from a single source.  Variance in sequence numbers
      between the two sources can then cause incorrect overload
      abatement treatment to be applied for indeterminate periods of
      time.

Section 4.2.1.1, 3rd paragraph:
Existing text:
   A realm-type OCS entry is identified by the pair of application-d and
   realm.
Comment: a letter "i" is missing.
Proposal: replace the paragraph with:
   A realm-type OCS entry is identified by the pair of application-id and
   realm.

Section 4.2.1.3, 3rd paragraph:
Existing text:
   When receiving an answer message with multiple OLRs or different
   types, a reporting node MUST process each received OLR.
Comment: The "or" is probably meant to be an "of". Furthermore, OLRs with u=
nsupported report types are not required to be processed.
Proposal: replace the paragraph with:
   When receiving an answer message with multiple OLRs of different
   supported report types, a reporting node MUST process each received OLR.

Section 4.2.1.3, 4th paragraph:
Existing text:
   When receiving an OC-OLR AVPs with unknown values, a reacting node
   SHOULD be silently discarded by reacting nodes and the event SHOULD
   be logged.
Comment: text is confusing. Maybe the intention was to say:
   When receiving an OC-OLR AVPs with an unsupported report type value, a r=
eacting node
   SHOULD silently discarded the OC-OLR AVP and the event SHOULD
   be logged.
But even that is not correct.
Proposal: Remove the paragraph.

Section 4.2.2, 5th and 6th paragraph:
Existing text:
   If the request is a host-routed request then the reacting node SHOULD
   apply throttling abatement treatment to the request.
=20
   If the request is a realm-routed request then the reacting node
   SHOULD apply diversion abatement treatment to the request.
Comment: I don't think so. If the reacting node selects the server and then=
 detects that the selected server is overloaded and then detects that the r=
equest does not survive (i.e. is subject to abatement), then the reacting n=
ode SHOULD apply diversion treatment (i.e. select an alternative server if =
possible). If the reacting node does not select the server (either a. becau=
se the server was already selected by a downstream node, or b. because the =
server will be selected by an upstream node) then there is no point in appl=
ying diversion and the reacting node SHOULD apply throttling of requests th=
at do not survive.
Proposal: replace the paragraphs with:
   If the reacting node does not select the server then it SHOULD apply
   throttling abatement to the request.

   If the reacting node selects the server then it SHOULD apply diversion
   abatement treatment (i.e. select an alternative server if possible) to
   the request.

Section 4.2.2, last paragraph:
Existing text:
   In the case that the OCS entry indicated no traffic was to be sent to
   the overloaded entity and the validity duration expires or has a
   validity duration of zero ("0"), meaning that the reporting node has
   explicitly signaled the end of the overload condition then overload
   abatement associated with the overload abatement MUST be ended in a
   controlled fashion.
Comment: If no traffic is sent, no OLR will be received, hence you cannot c=
ome out of a 100% throttling by explicit indication.
Proposal: replace the paragraph with:
   In the case that the OCS entry indicated no traffic was to be sent to
   the overloaded entity and the validity duration expires then overload
   abatement associated with the overload abatement MUST be ended in a
   controlled fashion.

Section 4.3, 3rd paragraph:
Existing text:
   The extension MAY define new AVPs for use in DOIC Capability
   Announcement and for use in DOIC Overload reporting.  These new AVPs
   SHOULD be defined to be extensions to the OC-Supported-Features and
   OC-OLR AVPs defined in this document.
Comment: It is not necessary for a new AVP to be an extension to both the O=
C-Supported-Features AVP and the OC-OLR AVP.
Proposal: Replace the paragraph with:
   The extension MAY define new AVPs for use in DOIC Capability
   Announcement and for use in DOIC Overload reporting.  These new AVPs
   SHOULD be defined to be extensions to the OC-Supported-Features and/or
   OC-OLR AVPs defined in this document.

Section 5.1, 9th paragraph:
Existing text:
   4.  The reacting node determines if overload abatement treatment
       should be applied to the request.  One approach that could be
       taken for each request is to select a random number between 1 and
       100.  If the random number is less than the indicated reduction
       percentage then the request is given abatement treatment,
       otherwise the request is given normal routing treatment.
Comment:The maths is wrong.
Proposal: Replace the paragraph with:
   4.  The reacting node determines if overload abatement treatment
       should be applied to the request.  One approach that could be
       taken for each request is to select a random number between 1 and
       100.  If the random number is less than or equal to the indicated
       reduction percentage then the request is given abatement treatment,
       otherwise the request is given normal routing treatment.

Section 5.3, 4th paragraph:
Existing text:
   When applying overload abatement treatment for the load abatement
   algorithm, the reacting node MUST abate the requested percentage of
   requests that would have otherwise been sent to the reporting host or
   realm.
Comment: probably a typo.
Proposal: Replace the paragraph with:
   When applying overload abatement treatment for the loss abatement
   algorithm, the reacting node MUST abate the requested percentage of
   requests that would have otherwise been sent to the reporting host or
   realm.

Section 5.3, 6th paragraph:
Existing text:
   If the reacting node does not receive an OLR in messages sent to the
   formerly overloaded node then the reacting node SHOULD slowly
   increase the rate of traffic sent to the overloaded node.
Comment: confusing.
Proposal: Replace paragraph with:
   If the reacting node does not receive an OLR in response to messages
   sent to the formerly overloaded node then the reacting node SHOULD
   slowly increase the rate of traffic sent to the overloaded node.

Section 6.1, last paragraph:
Existing text:
   The OC-Feature-Vector sub-AVP is used to announce the DOIC features
   supported by the DOIC node, in the form of a flag-bits field in which
   each bit announces one feature or capability supported by the node
   (see Section 6.2).  The absence of the OC-Feature-Vector AVP
   indicates that only the default traffic abatement algorithm described
   in this specification is supported.
Comment: Absence of OC-Feature-Vector AVP indicates different things depend=
ing on the type of message (request / answer).
Proposal: Replace the paragraph with:
   The OC-Feature-Vector sub-AVP is used to announce the DOIC features
   supported by the DOIC node, in the form of a flag-bits field in which
   each bit announces one feature or capability supported by the node
   (see Section 6.2).  The absence of the OC-Feature-Vector AVP in request
   messages indicates that only the default traffic abatement algorithm
   described in this specification is supported. The absence of the OC-
   Feature-Vector AVP in answer messages indicates that the default
   traffic abatement algorithm described in this specification is selected
   (while other traffic abatement algorithms may be supported), and no
   features other than abatement algorithms are supported.

Section 6.2, 2nd paragraph:
Existing text:
   The OC-Feature-Vector sub-AVP is used to announce the DOIC features
   supported by the DOIC node, in the form of a flag-bits field in which
   each bit announces one feature or capability supported by the node
   (see Section 6.2).  The absence of the OC-Feature-Vector AVP
   indicates that only the default traffic abatement algorithm described
   in this specification is supported.
Comment: seems to be misplaced as reference is given to 6.2.
Proposal: remove the paragraph.

Section 6.3, 1st paragraph:
Existing text:
   The OC-OLR AVP (AVP code TBD2) is of type Grouped and contains the
   information necessary to convey an overload report on an overload
   condition at the reporting node.  The OC-OLR AVP does not explicitly
   contain all information needed by the reacting node to decide whether
   a subsequent request must undergo abatement using the received
   reduction percentage.  The value of the OC-Report-Type AVP within the
   OC-OLR AVP indicates which implicit information is relevant for this
   decision (see Section 6.6).  The application the OC-OLR AVP applies
   to is the same as the Application-Id found in the Diameter message
   header.  The host or realm the OC-OLR AVP concerns is determined from
   the Origin-Host AVP and/or Origin-Realm AVP found in the
   encapsulating Diameter command.  The OC-OLR AVP is intended to be
   sent only by a reporting node.
Comment: Reduction percentage may not be used by all future algorithms.
Proposal: Replace the paragraph with:
   The OC-OLR AVP (AVP code TBD2) is of type Grouped and contains the
   information necessary to convey an overload report on an overload
   condition at the reporting node.  The OC-OLR AVP does not explicitly
   contain all information needed by the reacting node to decide whether
   a subsequent request must undergo abatement using the selected
   abatement algorithm.  The value of the OC-Report-Type AVP within the
   OC-OLR AVP indicates which implicit information is relevant for this
   decision (see Section 6.6).  The application the OC-OLR AVP applies
   to is the same as the Application-Id found in the Diameter message
   header.  The host or realm the OC-OLR AVP concerns is determined from
   the Origin-Host AVP and/or Origin-Realm AVP found in the
   encapsulating Diameter command.  The OC-OLR AVP is intended to be
   sent only by a reporting node.

Section 6.8, last character
Proposal: remove the "."

Section 8.2, last paragraph:
Existing text:
   See Section 6.2 for the initial assignment in the registry.  New
   types can be added using the Specification Required policy [RFC5226].
Comment: wrong reference.
Proposal: Replace the paragraph with:
   See Section 6.6 for the initial assignment in the registry.  New
   types can be added using the Specification Required policy [RFC5226].




-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni Korhonen
Sent: Wednesday, December 03, 2014 11:32 PM
To: dime@ietf.org
Subject: [Dime] WLGC #1 for draft-ietf-dime-ovli-05

Folks,

We have had a considerable update on the DOIC draft based on the=20
comments from the interim meeting, Honolulu meeting and discussions held=20
lately on the mailinglist. Authors/chairs think the -05 draft is now=20
ready for a WGLC and the rest of the potential comments can be handled=20
as WGLC comments.

This email starts a two week WGLC #1 for draft-ietf-dime-ovli-05. The=20
WGLC ends 18th Dec 2014 EOB (CET+1). Post your review comments and=20
concerns to the mailinglist. Also make use of the issue tracker=20
(remember to select "severity" as "in WG last call").

Lionel & Jouni

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Mon Dec  8 05:31:02 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508B41A8A6B for ; Mon,  8 Dec 2014 05:30:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMNe30Bk8GFS for ; Mon,  8 Dec 2014 05:30:52 -0800 (PST)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 671941A8A6C for ; Mon,  8 Dec 2014 05:30:52 -0800 (PST)
Received: from localhost ([::1]:37090 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XxyOq-0006C4-0h; Mon, 08 Dec 2014 05:30:52 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "dime issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: jouni.nospam@gmail.com
X-Trac-Project: dime
Date: Mon, 08 Dec 2014 13:30:51 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/88
Message-ID: <064.69cb533e2dbb732d0731c1452d36605e@trac.tools.ietf.org>
X-Trac-Ticket-ID: 88
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, dime@ietf.org
X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/aW5iF23R1JPNlutspMMyAuMPdH4
Cc: dime@ietf.org
Subject: [Dime] [dime] #88 (draft-ietf-dime-ovli): Editorials
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: dime@ietf.org
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Dec 2014 13:30:58 -0000

#88: Editorials

 In Section 7:

 OLD:
    condition SHOULD send a DIAMETER-TOO-BUSY error response, if it can

 NEW:
    condition SHOULD send a DIAMETER_TOO_BUSY error response, if it can

-- 
------------------------------------+------------------------------------
 Reporter:  jouni.nospam@gmail.com  |      Owner:  jouni.nospam@gmail.com
     Type:  defect                  |     Status:  new
 Priority:  trivial                 |  Milestone:
Component:  draft-ietf-dime-ovli    |    Version:
 Severity:  In WG Last Call         |   Keywords:
------------------------------------+------------------------------------

Ticket URL: 
dime 


From nobody Mon Dec  8 14:54:53 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8800C1A00B7 for ; Mon,  8 Dec 2014 14:54:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Level: 
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bpwI3two-pS for ; Mon,  8 Dec 2014 14:54:50 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBEA51A00B2 for ; Mon,  8 Dec 2014 14:54:49 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61044 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Xy7CZ-0006Dp-Kw for dime@ietf.org; Mon, 08 Dec 2014 14:54:48 -0800
Message-ID: <54862C38.1000403@usdonovans.com>
Date: Mon, 08 Dec 2014 16:54:48 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------070507070407050105040607"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/fRNVNaFFFxPYq1_WDe5hSdnfUIQ
Subject: [Dime] Ulrich suggested change number 1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Dec 2014 22:54:51 -0000

This is a multi-part message in MIME format.
--------------070507070407050105040607
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

I'll deal with each of your suggestion in a separate email to help 
ensure that nothing is missed.

For your first suggestion:

Section 3, last paragraph:
Existing text:
    While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
    that are "adjacent" for DOIC purposes may not be adjacent from a
    Diameter, or transport, perspective.  For example, one or more
    Diameter agents that do not support DOIC may exist between a given
    pair of reporting and reacting nodes, as long as those agents pass
    unknown AVPs through unchanged.  The report types described in this
    document can safely pass through non-supporting agents.  This may not
    be true for report types defined in future specifications.

Comment: while this is all not wrong, the existing text may convey the erring
impression that there cannot be a DOIC supporting agent on the path between a
reporting node and an adjacent reacting node.

Proposal: It is proposed to add the following sentence at the end of the paragraph:
    Another example is where one or more Diameter agents that do support
    DOIC may exist between a given pair of reporting and reacting nodes,
    as long as those agents pass OC-specific AVPs through unchanged.

I don't agree with the suggested change, as the DOIC supporting agents 
might need to change the OC-specific AVPs.  I also don't understand how 
the paragraph implies that there cannot be DOIC supporting agents in the 
path of the request.  It is talking specifically about the case where 
there agents do not support DOIC are in the path.  The remainder of the 
document makes it clear that there can be agents that do support DOIC in 
the path of a transaction.

I don't see the need for a change here.

Regards,

Steve

--------------070507070407050105040607
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Ulrich,

    

    I'll deal with each of your suggestion in a separate email to help
    ensure that nothing is missed.

    

    For your first suggestion:

    

    
    
Section 3, last paragraph:
Existing text:
   While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
   that are "adjacent" for DOIC purposes may not be adjacent from a
   Diameter, or transport, perspective.  For example, one or more
   Diameter agents that do not support DOIC may exist between a given
   pair of reporting and reacting nodes, as long as those agents pass
   unknown AVPs through unchanged.  The report types described in this
   document can safely pass through non-supporting agents.  This may not
   be true for report types defined in future specifications.

Comment: while this is all not wrong, the existing text may convey the erring 
impression that there cannot be a DOIC supporting agent on the path between a 
reporting node and an adjacent reacting node. 

Proposal: It is proposed to add the following sentence at the end of the paragraph:
   Another example is where one or more Diameter agents that do support
   DOIC may exist between a given pair of reporting and reacting nodes,
   as long as those agents pass OC-specific AVPs through unchanged.

    I don't agree with the suggested change, as the DOIC supporting
    agents might need to change the OC-specific AVPs.  I also don't
    understand how the paragraph implies that there cannot be DOIC
    supporting agents in the path of the request.  It is talking
    specifically about the case where there agents do not support DOIC
    are in the path.  The remainder of the document makes it clear that
    there can be agents that do support DOIC in the path of a
    transaction.

    

    I don't see the need for a change here.

    

    Regards,

    

    Steve

  


--------------070507070407050105040607--


From nobody Mon Dec  8 14:58:32 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334DC1A0089 for ; Mon,  8 Dec 2014 14:58:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ow-VgSrCKPgG for ; Mon,  8 Dec 2014 14:58:30 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113AF1A0086 for ; Mon,  8 Dec 2014 14:58:30 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61048 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Xy7G7-000Adi-Ti for dime@ietf.org; Mon, 08 Dec 2014 14:58:28 -0800
Message-ID: <54862D14.2060304@usdonovans.com>
Date: Mon, 08 Dec 2014 16:58:28 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------070302020700060104020106"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kuuhtkgS7bHs2l6f2SM06h8WWxY
Subject: [Dime] Ulrich suggested change number 2
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Dec 2014 22:58:31 -0000

This is a multi-part message in MIME format.
--------------070302020700060104020106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

For the second suggested change:

Section 3.2, 6th paragraph:
Existing text:
    The OC-Feature-Vector AVP will contain an indication of support for
    the loss overload abatement algorithm defined in this specification
    (see Section 5).  This ensures that there is at least one commonly
    supported overload abatement algorithm between the reporting node and
    the reacting node(s) in the path of the request.

Comment: I agree that within a given path between client and server there may
be more than one reacting nodes. But a given reporting node on that path does
not have more than one adjacent reacting nodes on that given path to which it
sends OLRs. I don't say that the existing text is wrong, but it is misleading.
What we want to say here is that any given pair of adjacent reacting and reporting
nodes will have at least one commonly supported algorithm.

Proposal: It is proposed to replace the last line of the paragraph with:
    The adjacent reacting node on the path of the request.

It's more than just about the adjacent reaction nodes.  It is important 
that all reacting nodes in the path of the request have at least one 
common abatement algorithm.

I don't see the need for the suggested change.

Regards,

Steve

--------------070302020700060104020106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Ulrich,

    

    For the second suggested change:

    

    
    
Section 3.2, 6th paragraph:
Existing text:
   The OC-Feature-Vector AVP will contain an indication of support for
   the loss overload abatement algorithm defined in this specification
   (see Section 5).  This ensures that there is at least one commonly
   supported overload abatement algorithm between the reporting node and
   the reacting node(s) in the path of the request.

Comment: I agree that within a given path between client and server there may 
be more than one reacting nodes. But a given reporting node on that path does 
not have more than one adjacent reacting nodes on that given path to which it 
sends OLRs. I don't say that the existing text is wrong, but it is misleading. 
What we want to say here is that any given pair of adjacent reacting and reporting 
nodes will have at least one commonly supported algorithm.

Proposal: It is proposed to replace the last line of the paragraph with:
   The adjacent reacting node on the path of the request.


    It's more than just about the adjacent reaction nodes.  It is
    important that all reacting nodes in the path of the request have at
    least one common abatement algorithm. 

    

    I don't see the need for the suggested change.

    

    Regards,

    

    Steve

  


--------------070302020700060104020106--


From nobody Mon Dec  8 15:07:06 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FCB1A00E1 for ; Mon,  8 Dec 2014 15:07:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4H_40G5uJ7D for ; Mon,  8 Dec 2014 15:07:04 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7531A00C5 for ; Mon,  8 Dec 2014 15:07:02 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61054 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Xy7ON-0008Rf-3p for dime@ietf.org; Mon, 08 Dec 2014 15:07:01 -0800
Message-ID: <54862F13.1060907@usdonovans.com>
Date: Mon, 08 Dec 2014 17:06:59 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------040806020804040607080001"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/GHVOwA_aqzRxZ5QzVz3xZPgPVhQ
Subject: [Dime] Ulrich suggested change number 3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Dec 2014 23:07:06 -0000

This is a multi-part message in MIME format.
--------------040806020804040607080001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

For suggested change number 3:

Section 3.2, last two paragraphs:
Existing text:
    The DCA mechanism must also allow the scenario where the set of
    features supported by the sender of a request and by agents in the
    path of a request differ.  In this case, the agent updates the OC-
    Supported-Features AVP to reflect the mixture of the two sets of
    supported features.

       Note: The logic to determine the content of the modified  OC-
       Supported-Features AVP is out-of-scope for this specification and
       is left to implementation decisions.  Care must be taken not to
       introduce interoperability issues for downstream or upstream DOIC
       nodes.

Comment: It is perfectly ok (in this case) for the agent not to update and not to modify.

Proposal: It is proposed to replace the two paragraphs with the following:
    The DCA mechanism must also allow the scenario where the set of
    features supported by the sender of a request and by agents in the
    path of a request differ.  In this case, the agent can update the OC-
    Supported-Features AVP to reflect the mixture of the two sets of
    supported features.

       Note: The logic to determine whether and if how to modify the
       content of the OC-Supported-Features AVP is out-of-scope for this
       specification and is left to implementation decisions.  Care must
       be taken not to introduce interoperability issues for downstream
       or upstream DOIC nodes.

I don't see the need for the change as the paragraph is talking 
specifically about the scenario where an agent would change the 
OC-Supported-Features AVP.   That said, the change in the first 
paragraph is ok.  If we make that change then I suggest a cleaned up 
first sentence of the next paragraph as follows:

"Note: The logic to determine if the content of the 
OC-Supported-Features AVP should be changed is out-of-scope for this 
document, as is the logic to determine the content of a modified 
OC-Supported-Features AVP.  These are left to implementation decisions..."

Regards,

Steve

--------------040806020804040607080001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Ulrich,

    

    For suggested change number 3:

    

    
    
Section 3.2, last two paragraphs:
Existing text:
   The DCA mechanism must also allow the scenario where the set of
   features supported by the sender of a request and by agents in the
   path of a request differ.  In this case, the agent updates the OC-
   Supported-Features AVP to reflect the mixture of the two sets of
   supported features.

      Note: The logic to determine the content of the modified  OC-
      Supported-Features AVP is out-of-scope for this specification and
      is left to implementation decisions.  Care must be taken not to
      introduce interoperability issues for downstream or upstream DOIC
      nodes.

Comment: It is perfectly ok (in this case) for the agent not to update and not to modify. 

Proposal: It is proposed to replace the two paragraphs with the following:
   The DCA mechanism must also allow the scenario where the set of
   features supported by the sender of a request and by agents in the
   path of a request differ.  In this case, the agent can update the OC-
   Supported-Features AVP to reflect the mixture of the two sets of
   supported features.

      Note: The logic to determine whether and if how to modify the
      content of the OC-Supported-Features AVP is out-of-scope for this
      specification and is left to implementation decisions.  Care must
      be taken not to introduce interoperability issues for downstream
      or upstream DOIC nodes.

    I don't see the need for the change as the paragraph is talking
    specifically about the scenario where an agent would change the
    OC-Supported-Features AVP.   That said, the change in the first
    paragraph is ok.  If we make that change then I suggest a cleaned up
    first sentence of the next paragraph as follows:

    

    "Note: The logic to determine if the content of the 
    OC-Supported-Features AVP should be changed is out-of-scope for this
    document, as is the logic to determine the content of a modified
    OC-Supported-Features AVP.  These are left to implementation
    decisions..."

    

    Regards,

    

    Steve

  


--------------040806020804040607080001--


From nobody Tue Dec  9 04:48:48 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658171A0363 for ; Tue,  9 Dec 2014 04:48:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mB_NvzPO6rRQ for ; Tue,  9 Dec 2014 04:48:45 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC99E1A0211 for ; Tue,  9 Dec 2014 04:48:45 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62865 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XyKDa-0003r2-Qg for dime@ietf.org; Tue, 09 Dec 2014 04:48:45 -0800
Message-ID: <5486EFAA.7090902@usdonovans.com>
Date: Tue, 09 Dec 2014 06:48:42 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------020209080004070907020907"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/RAXnicgQnPR8ock_QoG_O52C0Ko
Subject: [Dime] Ulrich suggested change number 4
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 12:48:47 -0000

This is a multi-part message in MIME format.
--------------020209080004070907020907
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

For your fourth suggested change:

Section 3.3, 4th and 5th paragraph:
Existing text:
    A report of type "HOST_REPORT" is sent to indicate the overload of a
    specific Diameter node for the application-id indicated in the
    transaction.  When receiving an OLR of type host, a reacting node
    applies overload abatement to what is referred to in this document as
    host-routed requests.  The reacting node applies overload abatement
    on those host-routed requests which the reacting node knows will be
    served by the server that matches the Origin-Host AVP of the received
    message that contained the received OLR of type host.

    A report of type "REALM_REPORT" applies to realm-routed requests for
    a specific realm as indicated in the Destination-Realm AVP.
Comment: While the 4th paragraph is all fine, the 5th paragraph should be aligned.
Proposal: It is proposed to replace the 5th paragraph with:
    A report of type "REALM_REPORT" is sent to indicate the overload of all
    Diameter nodes within a realm for the application-id indicated in the
    transaction.  When receiving an OLR of type realm, a reacting node
    applies overload abatement to what is referred to in this document as
    realm-routed requests.  The reacting node applies overload abatement
    on those realm-routed requests which contain  a Destination-Realm AVP
    that matches the Origin-Realm AVP of the received message that
    contained the received OLR of type realm.

I support the suggested change.

Regards,

Steve



--------------020209080004070907020907
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Ulrich,

    

    For your fourth suggested change:

    

    
    
Section 3.3, 4th and 5th paragraph:
Existing text:
   A report of type "HOST_REPORT" is sent to indicate the overload of a
   specific Diameter node for the application-id indicated in the
   transaction.  When receiving an OLR of type host, a reacting node
   applies overload abatement to what is referred to in this document as
   host-routed requests.  The reacting node applies overload abatement
   on those host-routed requests which the reacting node knows will be
   served by the server that matches the Origin-Host AVP of the received
   message that contained the received OLR of type host.

   A report of type "REALM_REPORT" applies to realm-routed requests for
   a specific realm as indicated in the Destination-Realm AVP.
Comment: While the 4th paragraph is all fine, the 5th paragraph should be aligned.
Proposal: It is proposed to replace the 5th paragraph with:
   A report of type "REALM_REPORT" is sent to indicate the overload of all
   Diameter nodes within a realm for the application-id indicated in the
   transaction.  When receiving an OLR of type realm, a reacting node
   applies overload abatement to what is referred to in this document as
   realm-routed requests.  The reacting node applies overload abatement
   on those realm-routed requests which contain  a Destination-Realm AVP
   that matches the Origin-Realm AVP of the received message that
   contained the received OLR of type realm.

    I support the suggested change.

    

    Regards,

    

    Steve

    

    

  


--------------020209080004070907020907--


From nobody Tue Dec  9 04:52:28 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4651A0451 for ; Tue,  9 Dec 2014 04:52:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4bCwsZs0VjB for ; Tue,  9 Dec 2014 04:52:15 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DCB11A0636 for ; Tue,  9 Dec 2014 04:52:15 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62871 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XyKH0-0007ha-44 for dime@ietf.org; Tue, 09 Dec 2014 04:52:14 -0800
Message-ID: <5486F07D.1010102@usdonovans.com>
Date: Tue, 09 Dec 2014 06:52:13 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------030709010306070201070705"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/OB5G9eLO5hfJsgKjMn0FhsG-_Oo
Subject: [Dime] Ulrich suggested change number 5
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 12:52:18 -0000

This is a multi-part message in MIME format.
--------------030709010306070201070705
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

For your suggested change number 5:

Section 3.3, 8th paragraph:
Existing text:
    Reporting nodes are responsible for determining the need for a
    reduction of traffic.  The method for making this determination is
    implementation specific and depend on the type of overload report
    being generated.  A host-report, for instance, will generally be
    generated by tracking utilization of resources required by the host
    to handle transactions for the Diameter application.  A realm-report
    generally impacts the traffic sent to multiple hosts and, as such,
    requires tracking the capacity all servers for realm-routed requests
    for the application and realm.
Comment: Something is wrong with the last sentence.
Proposal: Replace the last sentence with:
                                                          A realm-report
    generally impacts the traffic sent to multiple hosts and, as such,
    requires tracking the capacity of all servers able to handle realm-
    routed requests for the application and realm.


I support the change.

Regards,

Steve


--------------030709010306070201070705
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Ulrich,

    

    For your suggested change number 5:

    

    
    
Section 3.3, 8th paragraph:
Existing text:
   Reporting nodes are responsible for determining the need for a
   reduction of traffic.  The method for making this determination is
   implementation specific and depend on the type of overload report
   being generated.  A host-report, for instance, will generally be
   generated by tracking utilization of resources required by the host
   to handle transactions for the Diameter application.  A realm-report
   generally impacts the traffic sent to multiple hosts and, as such,
   requires tracking the capacity all servers for realm-routed requests
   for the application and realm.
Comment: Something is wrong with the last sentence.
Proposal: Replace the last sentence with:
                                                         A realm-report
   generally impacts the traffic sent to multiple hosts and, as such,
   requires tracking the capacity of all servers able to handle realm-
   routed requests for the application and realm.

    

    I support the change.

    

    Regards,

    

    Steve

    

  


--------------030709010306070201070705--


From nobody Tue Dec  9 04:54:13 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7212B1A0397 for ; Tue,  9 Dec 2014 04:54:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggRtLu6V3muW for ; Tue,  9 Dec 2014 04:54:11 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2A61A0395 for ; Tue,  9 Dec 2014 04:54:11 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62877 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XyKIs-0009fU-5d for dime@ietf.org; Tue, 09 Dec 2014 04:54:10 -0800
Message-ID: <5486F0F1.8000200@usdonovans.com>
Date: Tue, 09 Dec 2014 06:54:09 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------080400050602030707050104"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/_ifcDR-T0NfU4f43JXfzt7SeUro
Subject: [Dime] Ulrich's suggest change number 6
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 12:54:12 -0000

This is a multi-part message in MIME format.
--------------080400050602030707050104
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

For your suggested change #6:

Section 3.3, 12th paragraph:
Existing text:
    As the conditions that lead to the generation of the overload report
    change the reporting node can send new overload reports requesting
    greater reduction if the condition gets worse or less reduction if
    the condition improves.  The reporting node sends an overload report
    with a duration of zero to indicate that the overload condition has
    ended and need for use of the abatement algorithm to reduce traffic
    sent is no longer needed.
Comment: Bad style.
Proposal: Remove the words "need for" from the last sentence.

I support the suggested change.

Regards,

Steve



--------------080400050602030707050104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Ulrich,

    

    For your suggested change #6:

    

    
    
Section 3.3, 12th paragraph:
Existing text:
   As the conditions that lead to the generation of the overload report
   change the reporting node can send new overload reports requesting
   greater reduction if the condition gets worse or less reduction if
   the condition improves.  The reporting node sends an overload report
   with a duration of zero to indicate that the overload condition has
   ended and need for use of the abatement algorithm to reduce traffic
   sent is no longer needed.
Comment: Bad style.
Proposal: Remove the words "need for" from the last sentence.


    I support the suggested change.

    

    Regards,

    

    Steve

    

    

  


--------------080400050602030707050104--


From nobody Tue Dec  9 05:06:35 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1D11A09CF for ; Tue,  9 Dec 2014 05:06:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3IZG6wwpoMm for ; Tue,  9 Dec 2014 05:06:32 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98ED1A03A3 for ; Tue,  9 Dec 2014 05:06:32 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62897 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XyKUp-000Bkh-Cu for dime@ietf.org; Tue, 09 Dec 2014 05:06:32 -0800
Message-ID: <5486F3D7.7040305@usdonovans.com>
Date: Tue, 09 Dec 2014 07:06:31 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------090808070703080209060508"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/c9JFbZoIrfMqhpU1Rwx4iT2fyns
Subject: [Dime] Ulrich's suggested change #7
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 13:06:34 -0000

This is a multi-part message in MIME format.
--------------090808070703080209060508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

For your suggested change #7:

Section 4.1.2, 4th paragraph:
Existing text:
    A reporting node knows what overload control functionality is
    supported by the reacting node based on the content of the OC-
    Feature-Vector AVP in the request message.
Comment: The Feature-Vector AVP may be absent. In this case knowledge cannot be based on the content.
Proposal: Replace the paragraph with:
    A reporting node knows what overload control functionality is
    supported by the reacting node based on the content or absence of
    the OC-Feature-Vector AVP within the Supported-Features AVP in the
    request message.

I support the change with the modification of Supported-Features to 
OC-Supported-Features.

Regards,

Steve



--------------090808070703080209060508
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Ulrich,

    

    For your suggested change #7:

    

    
    
Section 4.1.2, 4th paragraph:
Existing text:
   A reporting node knows what overload control functionality is
   supported by the reacting node based on the content of the OC-
   Feature-Vector AVP in the request message.
Comment: The Feature-Vector AVP may be absent. In this case knowledge cannot be based on the content.
Proposal: Replace the paragraph with:
   A reporting node knows what overload control functionality is
   supported by the reacting node based on the content or absence of
   the OC-Feature-Vector AVP within the Supported-Features AVP in the
   request message.


    I support the change with the modification of Supported-Features to
    OC-Supported-Features.

    

    Regards,

    

    Steve

    

    

  


--------------090808070703080209060508--


From nobody Tue Dec  9 05:14:10 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30A21A1A74 for ; Tue,  9 Dec 2014 05:14:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5zgwS2qeuNC for ; Tue,  9 Dec 2014 05:14:07 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA6E1A1A6B for ; Tue,  9 Dec 2014 05:14:07 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62922 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XyKcA-0008dH-CB for dime@ietf.org; Tue, 09 Dec 2014 05:14:07 -0800
Message-ID: <5486F59E.4000908@usdonovans.com>
Date: Tue, 09 Dec 2014 07:14:06 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------070205040900030009050307"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/55YKKnfyM2x4RqSW23bmA9yfXVc
Subject: [Dime] Ulrich's suggested change #8
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 13:14:09 -0000

This is a multi-part message in MIME format.
--------------070205040900030009050307
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

For your suggested change number 8:

Section 4.1.2, 8th paragraph:
Existing text:
    For an ongoing overload condition, a reporting node MUST NOT change
    the selected algorithm during the period of time that it is in an
    overload condition and, as a result, is sending OC-OLR AVPs in answer
    messages.

Comment: As a result of an ongoing overload condition the reporting node is
sending OC-OLR AVPs containing no validity duration or a validity duration
different from zero in answer messages.

Proposal: Replace the paragraph with:
    For an ongoing overload condition, a reporting node MUST NOT change
    the selected algorithm during the period of time that it is in an
    overload condition and, as a result, is sending OC-OLR AVPs
    containing no validity duration or a validity duration different
    from zero in answer messages.

I don't see the need for the change.  The selected algorithm should not 
change for all overload reports relating to an overload condition, 
including overload reports with a validity duration of zero.

Regards,

Steve

--------------070205040900030009050307
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Ulrich,

    

    For your suggested change number 8:

    
    
Section 4.1.2, 8th paragraph:
Existing text:
   For an ongoing overload condition, a reporting node MUST NOT change
   the selected algorithm during the period of time that it is in an
   overload condition and, as a result, is sending OC-OLR AVPs in answer
   messages.

Comment: As a result of an ongoing overload condition the reporting node is 
sending OC-OLR AVPs containing no validity duration or a validity duration 
different from zero in answer messages.

Proposal: Replace the paragraph with:
   For an ongoing overload condition, a reporting node MUST NOT change
   the selected algorithm during the period of time that it is in an
   overload condition and, as a result, is sending OC-OLR AVPs
   containing no validity duration or a validity duration different
   from zero in answer messages.

    I don't see the need for the change.  The selected algorithm should
    not change for all overload reports relating to an overload
    condition, including overload reports with a validity duration of
    zero.

    

    Regards,

    

    Steve

  


--------------070205040900030009050307--


From nobody Tue Dec  9 05:16:45 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27161A1A64 for ; Tue,  9 Dec 2014 05:16:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugnVeIqQPyL9 for ; Tue,  9 Dec 2014 05:16:41 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E711A1A6B for ; Tue,  9 Dec 2014 05:16:40 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sB9DGdvY015731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Dec 2014 13:16:39 GMT
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sB9DGccW013523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 14:16:39 +0100
Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Dec 2014 14:16:38 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 14:16:38 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Ulrich suggested change number 1
Thread-Index: AQHQEzn9APTOpOEpnEOsWl042ZAFN5yHKxAQ
Date: Tue, 9 Dec 2014 13:16:38 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668152350CF@DEMUMBX014.nsn-intra.net>
References: <54862C38.1000403@usdonovans.com>
In-Reply-To: <54862C38.1000403@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 3667
X-purgate-ID: 151667::1418130999-0000658F-FB76D460/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5X_zzrjvRIujjhovRb2CsV5WUO4
Subject: Re: [Dime] Ulrich suggested change number 1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 13:16:43 -0000

Steve,

please see inline.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, December 08, 2014 11:55 PM
To: dime@ietf.org
Subject: [Dime] Ulrich suggested change number 1

Ulrich,

I'll deal with each of your suggestion in a separate email to help ensure t=
hat nothing is missed.

For your first suggestion:
Section 3, last paragraph:
Existing text:
   While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
   that are "adjacent" for DOIC purposes may not be adjacent from a
   Diameter, or transport, perspective.  For example, one or more
   Diameter agents that do not support DOIC may exist between a given
   pair of reporting and reacting nodes, as long as those agents pass
   unknown AVPs through unchanged.  The report types described in this
   document can safely pass through non-supporting agents.  This may not
   be true for report types defined in future specifications.

Comment: while this is all not wrong, the existing text may convey the erri=
ng=20
impression that there cannot be a DOIC supporting agent on the path between=
 a=20
reporting node and an adjacent reacting node.=20

Proposal: It is proposed to add the following sentence at the end of the pa=
ragraph:
   Another example is where one or more Diameter agents that do support
   DOIC may exist between a given pair of reporting and reacting nodes,
   as long as those agents pass OC-specific AVPs through unchanged.
I don't agree with the suggested change, as the DOIC supporting agents migh=
t need to change the OC-specific AVPs.
 I agree that in some cases DOIC supporting agents need to change t=
he OC-specific AVPs. However, there are also cases where DOIC supporting ag=
ents do not need to change OC-specific AVPs.
=A0 I also don't understand how the paragraph implies that there cannot be =
DOIC supporting agents in the path of the request.
 It does not imply that. Rather it may convey the erring impression=
 that there cannot be a DOIC supporting agent on the path between a=20
reporting node and an adjacent reacting node.
 =A0 It is talking specifically about the case where there agents do not su=
pport DOIC are in the path.
 No, my understanding is that the paragraph is talking specifically=
 about what "adjacent for DOIC purposes" means. One valid example is given =
(reporting node and reacting node are "adjacent for DOIC purposes" if one o=
r more agents that do not support DOIC but pass unsupported AVPs through un=
changed exist between reporting node and reacting node) and I do not propos=
e to remove that. However, there is another important valid example (report=
ing node and reacting node are "adjacent for DOIC purposes" if one or more =
DOIC supporting agents that pass OC-specific AVPs through unchanged exist b=
etween reporting node and reacting node), and the proposal is to add text t=
o cover this example. 
The remainder of the document makes it clear that there can be agents that =
do support DOIC in the path of a transaction.
 that is not my point. The point is to clearly state that there can=
 be DOIC supporting agents that pass through OC-specific AVPs unchanged on =
the path between reporting node and reacting node, and in this case the rep=
orting and reacting nodes are still regarded "adjacent for DOIC purposes".<=
/Ulrich> =20

I don't see the need for a change here.
 I'm not proposing a modification but an addition. This addition pr=
ovides useful clarification and in no way is harmful

Regards,

Steve


From nobody Tue Dec  9 05:35:20 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29041A1AF8 for ; Tue,  9 Dec 2014 05:35:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92ouZIMk4xqN for ; Tue,  9 Dec 2014 05:35:10 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CAB71A0266 for ; Tue,  9 Dec 2014 05:35:10 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62949 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XyKwV-0006Zp-JE for dime@ietf.org; Tue, 09 Dec 2014 05:35:09 -0800
Message-ID: <5486FA8B.6040503@usdonovans.com>
Date: Tue, 09 Dec 2014 07:35:07 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------030907020406050408020101"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/APf4vmTGrIhbr45r8UynSR761m4
Subject: [Dime] Ulrich's suggested changes #9 and #10
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 13:35:16 -0000

This is a multi-part message in MIME format.
--------------030907020406050408020101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

Suggested changes 9 and 10 are linked so I'll deal with them in a single 
email:

Section 4.1.3, 1st paragraph:
Existing text:
    Diameter Agents that support DOIC SHOULD ensure that all messages
    relayed by the agent contain the OC-Supported-Features AVP.
Comment: The SHOULD in the first line is not correct based on my next comment.
Proposal: Delete the first paragraph.

Section 4.1.3, 4th paragraph:
Existing text:
    A Diameter Agent SHOULD take on reporting node behavior for Diameter
    endpoints that do not support the DOIC solution.  A Diameter Agent
    detects that a Diameter endpoint does not support DOIC reporting node
    behavior when there is no OC-Supported-Features AVP in an answer
    message for a transaction that contained the OC-Supported-Features
    AVP in the request message.
Comment: The first sentence can reasonably only apply to Diameter agents that are immediate peers to the non-supporting Diameter endpoint. We cannot expect a far-away-agent to take on reporting node behavior when all upstream agents and the server do not support DOIC. Furthermore: When the non-supporting server has two DOIC supporting immediate peer agents which both take on reporting node behavior we end up in problems similar to those identified in the note in section 3.3.
Proposal:Replace the paragaph with:
    A Diameter Agent that is an immediate peer to the Diameter endpoint
    that does not support DOIC SHOULD take on reporting node behavior for
    Diameter endpoints that do not support the DOIC solution.  A Diameter
    Agent detects that a Diameter endpoint does not support DOIC reporting
    node behavior when there is no OC-Supported-Features AVP in an answer
    message for a transaction that contained the OC-Supported-Features
    AVP in the request message.
       Note: Known issues exist if multiple sources for overload reports
       which apply to the same Diameter entity exist.  Reacting nodes
       have no way of determining the source and, as such, will treat
       them as coming from a single source.  Variance in sequence numbers
       between the two sources can then cause incorrect overload
       abatement treatment to be applied for indeterminate periods of
       time.

You point out an interesting issue with agents taking on reporting node 
functionality.

I don't, however, think that an agent that takes on reporting node 
functionality for a non supporting host needs to be adjacent to the 
host.  The important thing is that it has visibility to all of the 
traffic sent to the host.

I suggest keeping the first paragraph but changing the SHOULD to a MAY.

I also suggest changing the SHOULD to a MAY in the fourth paragraph and 
changing the first sentence to:

A Diameter Agent MAY take on reporting node behavior for Diameter 
endpoints that do not support the DOIC solution.  The Diameter Agent 
MUST have visibility to all traffic destined for the non supporting host 
in order to become the reporting node for the Diameter endpoint.

Regards,

Steve

--------------030907020406050408020101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Ulrich,

    

    Suggested changes 9 and 10 are linked so I'll deal with them in a
    single email:

    

    
    
Section 4.1.3, 1st paragraph:
Existing text:
   Diameter Agents that support DOIC SHOULD ensure that all messages
   relayed by the agent contain the OC-Supported-Features AVP.
Comment: The SHOULD in the first line is not correct based on my next comment.
Proposal: Delete the first paragraph. 

Section 4.1.3, 4th paragraph:
Existing text:
   A Diameter Agent SHOULD take on reporting node behavior for Diameter
   endpoints that do not support the DOIC solution.  A Diameter Agent
   detects that a Diameter endpoint does not support DOIC reporting node
   behavior when there is no OC-Supported-Features AVP in an answer
   message for a transaction that contained the OC-Supported-Features
   AVP in the request message.
Comment: The first sentence can reasonably only apply to Diameter agents that are immediate peers to the non-supporting Diameter endpoint. We cannot expect a far-away-agent to take on reporting node behavior when all upstream agents and the server do not support DOIC. Furthermore: When the non-supporting server has two DOIC supporting immediate peer agents which both take on reporting node behavior we end up in problems similar to those identified in the note in section 3.3.
Proposal:Replace the paragaph with:
   A Diameter Agent that is an immediate peer to the Diameter endpoint
   that does not support DOIC SHOULD take on reporting node behavior for
   Diameter endpoints that do not support the DOIC solution.  A Diameter
   Agent detects that a Diameter endpoint does not support DOIC reporting
   node behavior when there is no OC-Supported-Features AVP in an answer
   message for a transaction that contained the OC-Supported-Features
   AVP in the request message.
      Note: Known issues exist if multiple sources for overload reports
      which apply to the same Diameter entity exist.  Reacting nodes
      have no way of determining the source and, as such, will treat
      them as coming from a single source.  Variance in sequence numbers
      between the two sources can then cause incorrect overload
      abatement treatment to be applied for indeterminate periods of
      time.

    You point out an interesting issue with agents taking on reporting
    node functionality.

    

    I don't, however, think that an agent that takes on reporting node
    functionality for a non supporting host needs to be adjacent to the
    host.  The important thing is that it has visibility to all of the
    traffic sent to the host.

    

    I suggest keeping the first paragraph but changing the SHOULD to a
    MAY.

    

    I also suggest changing the SHOULD to a MAY in the fourth paragraph
    and changing the first sentence to:

    

    A Diameter Agent MAY take on reporting node behavior for Diameter
    endpoints that do not support the DOIC solution.  The Diameter Agent
    MUST have visibility to all traffic destined for the non supporting
    host in order to become the reporting node for the Diameter
    endpoint.

    

    Regards,

    

    Steve

  


--------------030907020406050408020101--


From nobody Tue Dec  9 05:39:56 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C421A1B05 for ; Tue,  9 Dec 2014 05:39:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TD_ixzgv3bWR for ; Tue,  9 Dec 2014 05:39:54 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F93E1A1AF6 for ; Tue,  9 Dec 2014 05:39:54 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62954 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XyL16-000B8g-Go for dime@ietf.org; Tue, 09 Dec 2014 05:39:53 -0800
Message-ID: <5486FBA8.9020206@usdonovans.com>
Date: Tue, 09 Dec 2014 07:39:52 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------020608000006000909060109"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/K1cxATC3QdtkIvSvTdyYh4e8m5M
Subject: [Dime] Ulrich's suggested change #11
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 13:39:55 -0000

This is a multi-part message in MIME format.
--------------020608000006000909060109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

For your  suggested change #11:

Section 4.1.3, 6th paragraph:
Existing text:
    As with a Diameter endpoint taking on reporting node behavior, a
    Diameter Agent MUST only include the OC-Supported-Features AVP in
    answer messages for transactions where the request message received
    by the Diameter Agent had an OC-Supported-Features AVP.
Comments: "MUST only do x for condition y" could mean:
a) "MUST do x for condition y and MUST NOT do x for conditions other than y", or
b) "MUST do x and nothing else for condition y, and nothing is specified for conditions other than y".
Proposal: Replace the paragraph with:
    As with a Diameter endpoint taking on reporting node behavior, a
    Diameter Agent MUST NOT include the OC-Supported-Features AVP in
    answer messages for transactions where the request message received
    by the Diameter Agent had no OC-Supported-Features AVP.

I support this change.

Regards,

Steve



--------------020608000006000909060109
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Ulrich,

    

    For your  suggested change #11:

    

    
    
Section 4.1.3, 6th paragraph:
Existing text:
   As with a Diameter endpoint taking on reporting node behavior, a
   Diameter Agent MUST only include the OC-Supported-Features AVP in
   answer messages for transactions where the request message received
   by the Diameter Agent had an OC-Supported-Features AVP.
Comments: "MUST only do x for condition y" could mean:
a) "MUST do x for condition y and MUST NOT do x for conditions other than y", or
b) "MUST do x and nothing else for condition y, and nothing is specified for conditions other than y".
Proposal: Replace the paragraph with:
   As with a Diameter endpoint taking on reporting node behavior, a
   Diameter Agent MUST NOT include the OC-Supported-Features AVP in
   answer messages for transactions where the request message received
   by the Diameter Agent had no OC-Supported-Features AVP.

    I support this change.

    

    Regards,

    

    Steve

    

    

  


--------------020608000006000909060109--


From nobody Tue Dec  9 05:44:36 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D8C1A1ADF for ; Tue,  9 Dec 2014 05:44:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrXH-iEkfBR5 for ; Tue,  9 Dec 2014 05:44:34 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502A01A1AEA for ; Tue,  9 Dec 2014 05:44:33 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62960 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XyL5b-0003OH-Qv for dime@ietf.org; Tue, 09 Dec 2014 05:44:32 -0800
Message-ID: <5486FCBF.4000707@usdonovans.com>
Date: Tue, 09 Dec 2014 07:44:31 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------010909040804010507060209"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dOi9GT3tbwI6qtizQg5-Gz0inTw
Subject: [Dime] Ulrich's suggested change @12
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 13:44:36 -0000

This is a multi-part message in MIME format.
--------------010909040804010507060209
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

For your suggested change #12:

Section 4.1.3, last paragraph:
Existing text:
    When making changes to the OC-Supported-Features AVP the Diameter
    Agent needs to ensure that there is no ambiguity in DOIC behavior for
    both upstream and downstream DOIC nodes.

Comment: while that is true, in addition problems similar to those
identified in the note in section 3.3 may result from making changes.

Proposal: Add the note:
       Note: Known issues exist if multiple sources for overload reports
       which apply to the same Diameter entity exist.  Reacting nodes
       have no way of determining the source and, as such, will treat
       them as coming from a single source.  Variance in sequence numbers
       between the two sources can then cause incorrect overload
       abatement treatment to be applied for indeterminate periods of
       time.

I don't understand how these are related.  The change to the 
OC-Supported-Features AVP made by the agent apply only to the 
transaction.  In addition, this paragraph doesn't mention overload reports.

Regards,

Steve



--------------010909040804010507060209
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Ulrich,

    

    For your suggested change #12:

    

    
    
Section 4.1.3, last paragraph:
Existing text:
   When making changes to the OC-Supported-Features AVP the Diameter
   Agent needs to ensure that there is no ambiguity in DOIC behavior for
   both upstream and downstream DOIC nodes.

Comment: while that is true, in addition problems similar to those 
identified in the note in section 3.3 may result from making changes.

Proposal: Add the note:
      Note: Known issues exist if multiple sources for overload reports
      which apply to the same Diameter entity exist.  Reacting nodes
      have no way of determining the source and, as such, will treat
      them as coming from a single source.  Variance in sequence numbers
      between the two sources can then cause incorrect overload
      abatement treatment to be applied for indeterminate periods of
      time.

    I don't understand how these are related.  The change to the
    OC-Supported-Features AVP made by the agent apply only to the
    transaction.  In addition, this paragraph doesn't mention overload
    reports.

    

    Regards,

    

    Steve

    

    

  


--------------010909040804010507060209--


From nobody Tue Dec  9 05:46:15 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBE21A0368 for ; Tue,  9 Dec 2014 05:46:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.899
X-Spam-Level: 
X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZPm-lB_Aq-s for ; Tue,  9 Dec 2014 05:46:13 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F0B21A1B21 for ; Tue,  9 Dec 2014 05:46:13 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62962 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XyL7B-0005CV-Nz for dime@ietf.org; Tue, 09 Dec 2014 05:46:12 -0800
Message-ID: <5486FD21.8010201@usdonovans.com>
Date: Tue, 09 Dec 2014 07:46:09 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------050104070605050105060608"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/90wM7LwNhaX564Y820zTNW1az1Q
Subject: [Dime] Ulrich's suggested change #13
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 13:46:14 -0000

This is a multi-part message in MIME format.
--------------050104070605050105060608
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

For you suggested change #13:

Section 4.2.1.1, 3rd paragraph:
Existing text:
    A realm-type OCS entry is identified by the pair of application-d and
    realm.
Comment: a letter "i" is missing.
Proposal: replace the paragraph with:
    A realm-type OCS entry is identified by the pair of application-id and
    realm.

I support the suggested change.

Steve


--------------050104070605050105060608
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Ulrich,

    

    For you suggested change #13:

    

    
    
Section 4.2.1.1, 3rd paragraph:
Existing text:
   A realm-type OCS entry is identified by the pair of application-d and
   realm.
Comment: a letter "i" is missing.
Proposal: replace the paragraph with:
   A realm-type OCS entry is identified by the pair of application-id and
   realm.

    I support the suggested change.

    

    Steve

    

  


--------------050104070605050105060608--


From nobody Tue Dec  9 05:49:06 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED0D1A1B2A for ; Tue,  9 Dec 2014 05:49:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDhTfqWkV6v9 for ; Tue,  9 Dec 2014 05:49:04 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B54401A1ADF for ; Tue,  9 Dec 2014 05:49:04 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62970 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XyL9z-00086b-F2 for dime@ietf.org; Tue, 09 Dec 2014 05:49:04 -0800
Message-ID: <5486FDCE.2010707@usdonovans.com>
Date: Tue, 09 Dec 2014 07:49:02 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------010902070805070003070905"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/OMOUjVO43t-pC75bDw5mZh2WMP0
Subject: [Dime] Ulrich's suggested change #14
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 13:49:06 -0000

This is a multi-part message in MIME format.
--------------010902070805070003070905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

For you suggested change number 14:

Section 4.2.1.3, 3rd paragraph:
Existing text:
    When receiving an answer message with multiple OLRs or different
    types, a reporting node MUST process each received OLR.
Comment: The "or" is probably meant to be an "of". Furthermore, OLRs with unsupported report types are not required to be processed.
Proposal: replace the paragraph with:
    When receiving an answer message with multiple OLRs of different
    supported report types, a reporting node MUST process each received OLR.


I supported the suggested change.

Regards,

Steve


--------------010902070805070003070905
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Ulrich,

    

    For you suggested change number 14:

    

    
    
Section 4.2.1.3, 3rd paragraph:
Existing text:
   When receiving an answer message with multiple OLRs or different
   types, a reporting node MUST process each received OLR.
Comment: The "or" is probably meant to be an "of". Furthermore, OLRs with unsupported report types are not required to be processed.
Proposal: replace the paragraph with:
   When receiving an answer message with multiple OLRs of different
   supported report types, a reporting node MUST process each received OLR.

    

    I supported the suggested change.

    

    Regards,

    

    Steve

    

  


--------------010902070805070003070905--


From nobody Tue Dec  9 05:51:50 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610001A1A7A for ; Tue,  9 Dec 2014 05:51:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niwN4s13gqZl for ; Tue,  9 Dec 2014 05:51:48 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 527761A1B0D for ; Tue,  9 Dec 2014 05:51:48 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62973 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XyLCb-000AwQ-OL for dime@ietf.org; Tue, 09 Dec 2014 05:51:47 -0800
Message-ID: <5486FE71.70205@usdonovans.com>
Date: Tue, 09 Dec 2014 07:51:45 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------080708070700090403080504"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5PJcC1O70CQh2-n51uY8qwuTYMo
Subject: [Dime] Ulrich's suggested change #15
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 13:51:49 -0000

This is a multi-part message in MIME format.
--------------080708070700090403080504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

For your suggested change #15:

Section 4.2.1.3, 4th paragraph:
Existing text:
    When receiving an OC-OLR AVPs with unknown values, a reacting node
    SHOULD be silently discarded by reacting nodes and the event SHOULD
    be logged.
Comment: text is confusing. Maybe the intention was to say:
    When receiving an OC-OLR AVPs with an unsupported report type value, a reacting node
    SHOULD silently discarded the OC-OLR AVP and the event SHOULD
    be logged.
But even that is not correct.
Proposal: Remove the paragraph.

The intent was that an OC-OLR that contains unknown values should be 
discarded.  I agree that the wording needs to be changes as you 
suggested.  I don't agree with removing the paragraph.  Can you 
elaborate on why you think it is not correct when changed as you suggested?

Regards,

Steve


--------------080708070700090403080504
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Ulrich,

    

    For your suggested change #15:

    

    
    
Section 4.2.1.3, 4th paragraph:
Existing text:
   When receiving an OC-OLR AVPs with unknown values, a reacting node
   SHOULD be silently discarded by reacting nodes and the event SHOULD
   be logged.
Comment: text is confusing. Maybe the intention was to say:
   When receiving an OC-OLR AVPs with an unsupported report type value, a reacting node
   SHOULD silently discarded the OC-OLR AVP and the event SHOULD
   be logged.
But even that is not correct.
Proposal: Remove the paragraph.


    The intent was that an OC-OLR that contains unknown values should be
    discarded.  I agree that the wording needs to be changes as you
    suggested.  I don't agree with removing the paragraph.  Can you
    elaborate on why you think it is not correct when changed as you
    suggested?

    

    Regards,

    

    Steve

    

  


--------------080708070700090403080504--


From nobody Tue Dec  9 06:06:31 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64F01A1EF9 for ; Tue,  9 Dec 2014 06:06:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgvrNKOWSXzH for ; Tue,  9 Dec 2014 06:06:27 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 035871A1BC9 for ; Tue,  9 Dec 2014 06:06:26 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63035 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XyLQn-0001zY-Bz for dime@ietf.org; Tue, 09 Dec 2014 06:06:26 -0800
Message-ID: <548701E1.3060502@usdonovans.com>
Date: Tue, 09 Dec 2014 08:06:25 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------020405090100040603030603"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/O7t2PQTT7G15jijb6tA7WvawKgY
Subject: [Dime] Ulrich's suggested change #16
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 14:06:30 -0000

This is a multi-part message in MIME format.
--------------020405090100040603030603
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

For your suggested change #16:

Section 4.2.2, 5th and 6th paragraph:
Existing text:
    If the request is a host-routed request then the reacting node SHOULD
    apply throttling abatement treatment to the request.
  
    If the request is a realm-routed request then the reacting node
    SHOULD apply diversion abatement treatment to the request.

Comment: I don't think so. If the reacting node selects the server and
then detects that the selected server is overloaded and then detects that
the request does not survive (i.e. is subject to abatement), then the reacting
node SHOULD apply diversion treatment (i.e. select an alternative server if possible).
If the reacting node does not select the server (either a. because the server was
already selected by a downstream node, or b. because the server will be selected
by an upstream node) then there is no point in applying diversion and the reacting
node SHOULD apply throttling of requests that do not survive.

Proposal: replace the paragraphs with:
    If the reacting node does not select the server then it SHOULD apply
    throttling abatement to the request.

    If the reacting node selects the server then it SHOULD apply diversion
    abatement treatment (i.e. select an alternative server if possible) to
    the request.

Diversion is not selecting an alternative node to handle the request.  
Diversion is selecting an alternative route to the selected node.

Whether it is appropriate to select an alternative node for a request is 
an application decision that probably changes on a per command-code 
basis within the application.  Logic like this is outside the scope of 
the DOIC specification.

The text is correct based on the definition of diversion.

Regards,

Steve

--------------020405090100040603030603
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Ulrich,

    

    For your suggested change #16:

    

    
    
Section 4.2.2, 5th and 6th paragraph:
Existing text:
   If the request is a host-routed request then the reacting node SHOULD
   apply throttling abatement treatment to the request.
 
   If the request is a realm-routed request then the reacting node
   SHOULD apply diversion abatement treatment to the request.

Comment: I don't think so. If the reacting node selects the server and 
then detects that the selected server is overloaded and then detects that 
the request does not survive (i.e. is subject to abatement), then the reacting 
node SHOULD apply diversion treatment (i.e. select an alternative server if possible). 
If the reacting node does not select the server (either a. because the server was 
already selected by a downstream node, or b. because the server will be selected 
by an upstream node) then there is no point in applying diversion and the reacting 
node SHOULD apply throttling of requests that do not survive.

Proposal: replace the paragraphs with:
   If the reacting node does not select the server then it SHOULD apply
   throttling abatement to the request.

   If the reacting node selects the server then it SHOULD apply diversion
   abatement treatment (i.e. select an alternative server if possible) to
   the request.

    Diversion is not selecting an alternative node to handle the
    request.  Diversion is selecting an alternative route to the
    selected node.  

    

    Whether it is appropriate to select an alternative node for a
    request is an application decision that probably changes on a per
    command-code basis within the application.  Logic like this is
    outside the scope of the DOIC specification.

    

    The text is correct based on the definition of diversion.

    

    Regards,

    

    Steve

  


--------------020405090100040603030603--


From nobody Tue Dec  9 06:09:07 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6751A6F53 for ; Tue,  9 Dec 2014 06:09:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_UlkhofjTUh for ; Tue,  9 Dec 2014 06:09:00 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4022E1A6F20 for ; Tue,  9 Dec 2014 06:08:27 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sB9E8P2S025703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Dec 2014 14:08:25 GMT
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sB9E8OPE008122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 15:08:24 +0100
Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Dec 2014 15:08:24 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 15:08:24 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Ulrich suggested change number 2
Thread-Index: AQHQEzp/NeYxnYFinESbfvW92bFjMJyHQOig
Date: Tue, 9 Dec 2014 14:08:23 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815235122@DEMUMBX014.nsn-intra.net>
References: <54862D14.2060304@usdonovans.com>
In-Reply-To: <54862D14.2060304@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2459
X-purgate-ID: 151667::1418134105-0000658F-3EB90BE6/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5HKQRYRVoy1kcSzeWXSz0GB3qr0
Subject: Re: [Dime] Ulrich suggested change number 2
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 14:09:06 -0000

Steve,

please see inline.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, December 08, 2014 11:58 PM
To: dime@ietf.org
Subject: [Dime] Ulrich suggested change number 2

Ulrich,

For the second suggested change:
Section 3.2, 6th paragraph:
Existing text:
   The OC-Feature-Vector AVP will contain an indication of support for
   the loss overload abatement algorithm defined in this specification
   (see Section 5).  This ensures that there is at least one commonly
   supported overload abatement algorithm between the reporting node and
   the reacting node(s) in the path of the request.

Comment: I agree that within a given path between client and server there m=
ay=20
be more than one reacting nodes. But a given reporting node on that path do=
es=20
not have more than one adjacent reacting nodes on that given path to which =
it=20
sends OLRs. I don't say that the existing text is wrong, but it is misleadi=
ng.=20
What we want to say here is that any given pair of adjacent reacting and re=
porting=20
nodes will have at least one commonly supported algorithm.

Proposal: It is proposed to replace the last line of the paragraph with:
   The adjacent reacting node on the path of the request.
It's more than just about the adjacent reaction nodes.=A0 It is important t=
hat all reacting nodes in the path of the request have at least one common =
abatement algorithm.=20
I do not agree. It is important that a pair of two adjacent reactin=
g and reporting nodes (A,S) have at least one commonly supported algorithm,=
 so that the reporting node can always select an algorithm supported by the=
 adjacent reacting node. There may be another (non-adjacent) reacting node =
in the path (C), but its not important for C and S (which are not adjacent)=
 to have a commonly supported algorithm.
C---A---S
It is important that C and A have a commonly supported algorith, as C and A=
 are adjacent;
It is important that A and S have a commonly supported algorith, as A and S=
 are adjacent;
It is true but not important (and nothing that needs to be ensured) that C =
and S have a commonly supported algorithm (indeed S could eventually select=
 an algorithm not supported by C);
It is true but not important that C, A and S have a commonly supported algo=
rithm.

I don't see the need for the suggested change.

Regards,

Steve


From nobody Tue Dec  9 06:10:21 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7F91A6F9F for ; Tue,  9 Dec 2014 06:10:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqlPTIzlIV1k for ; Tue,  9 Dec 2014 06:10:06 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B561A6F39 for ; Tue,  9 Dec 2014 06:09:57 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63037 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XyLUC-000689-D9 for dime@ietf.org; Tue, 09 Dec 2014 06:09:57 -0800
Message-ID: <548702B4.3070806@usdonovans.com>
Date: Tue, 09 Dec 2014 08:09:56 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------020709060508090601020609"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/hQlaN2UUbhJGD5DgQasZhH_wABg
Subject: [Dime] Ulrich's suggested change #17
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 14:10:12 -0000

This is a multi-part message in MIME format.
--------------020709060508090601020609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

For your suggested change #17:

Section 4.2.2, last paragraph:
Existing text:
    In the case that the OCS entry indicated no traffic was to be sent to
    the overloaded entity and the validity duration expires or has a
    validity duration of zero ("0"), meaning that the reporting node has
    explicitly signaled the end of the overload condition then overload
    abatement associated with the overload abatement MUST be ended in a
    controlled fashion.
Comment: If no traffic is sent, no OLR will be received, hence you cannot come out of a 100% throttling by explicit indication.
Proposal: replace the paragraph with:
    In the case that the OCS entry indicated no traffic was to be sent to
    the overloaded entity and the validity duration expires then overload
    abatement associated with the overload abatement MUST be ended in a
    controlled fashion.

I agree with the change with one additional modification - change the 
last abatement to report to make it:

    In the case that the OCS entry indicated no traffic was to be sent to
    the overloaded entity and the validity duration expires then overload
    abatement associated with the overload report MUST be ended in a
    controlled fashion.

Regards,

Steve





--------------020709060508090601020609
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Ulrich,

    

    For your suggested change #17:

    

    
    
Section 4.2.2, last paragraph:
Existing text:
   In the case that the OCS entry indicated no traffic was to be sent to
   the overloaded entity and the validity duration expires or has a
   validity duration of zero ("0"), meaning that the reporting node has
   explicitly signaled the end of the overload condition then overload
   abatement associated with the overload abatement MUST be ended in a
   controlled fashion.
Comment: If no traffic is sent, no OLR will be received, hence you cannot come out of a 100% throttling by explicit indication.
Proposal: replace the paragraph with:
   In the case that the OCS entry indicated no traffic was to be sent to
   the overloaded entity and the validity duration expires then overload
   abatement associated with the overload abatement MUST be ended in a
   controlled fashion.


    I agree with the change with one additional modification - change
    the last abatement to report to make it:

    

    
   In the case that the OCS entry indicated no traffic was to be sent to
   the overloaded entity and the validity duration expires then overload
   abatement associated with the overload report MUST be ended in a
   controlled fashion.

    Regards,

    

    Steve

    

    

    

    

  


--------------020709060508090601020609--


From nobody Tue Dec  9 06:20:00 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E960A1A6FA3 for ; Tue,  9 Dec 2014 06:19:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH6amf3rcQ8w for ; Tue,  9 Dec 2014 06:19:58 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72E7B1A6F99 for ; Tue,  9 Dec 2014 06:19:58 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63044 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XyLds-0005Pj-Tq for dime@ietf.org; Tue, 09 Dec 2014 06:19:57 -0800
Message-ID: <5487050C.8080206@usdonovans.com>
Date: Tue, 09 Dec 2014 08:19:56 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------090602090608070107090008"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ApZX6FCgmzVihL4oU4JXLJR4AW0
Subject: [Dime] Ulrich suggested changes 18, 19, 20 and 21
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 14:20:00 -0000

This is a multi-part message in MIME format.
--------------090602090608070107090008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

I support the suggested changes in your suggested changes 18, 19, 20 and 21:

Section 4.3, 3rd paragraph:
Existing text:
    The extension MAY define new AVPs for use in DOIC Capability
    Announcement and for use in DOIC Overload reporting.  These new AVPs
    SHOULD be defined to be extensions to the OC-Supported-Features and
    OC-OLR AVPs defined in this document.
Comment: It is not necessary for a new AVP to be an extension to both the OC-Supported-Features AVP and the OC-OLR AVP.
Proposal: Replace the paragraph with:
    The extension MAY define new AVPs for use in DOIC Capability
    Announcement and for use in DOIC Overload reporting.  These new AVPs
    SHOULD be defined to be extensions to the OC-Supported-Features and/or
    OC-OLR AVPs defined in this document.

Section 5.1, 9th paragraph:
Existing text:
    4.  The reacting node determines if overload abatement treatment
        should be applied to the request.  One approach that could be
        taken for each request is to select a random number between 1 and
        100.  If the random number is less than the indicated reduction
        percentage then the request is given abatement treatment,
        otherwise the request is given normal routing treatment.
Comment:The maths is wrong.
Proposal: Replace the paragraph with:
    4.  The reacting node determines if overload abatement treatment
        should be applied to the request.  One approach that could be
        taken for each request is to select a random number between 1 and
        100.  If the random number is less than or equal to the indicated
        reduction percentage then the request is given abatement treatment,
        otherwise the request is given normal routing treatment.

Section 5.3, 4th paragraph:
Existing text:
    When applying overload abatement treatment for the load abatement
    algorithm, the reacting node MUST abate the requested percentage of
    requests that would have otherwise been sent to the reporting host or
    realm.
Comment: probably a typo.
Proposal: Replace the paragraph with:
    When applying overload abatement treatment for the loss abatement
    algorithm, the reacting node MUST abate the requested percentage of
    requests that would have otherwise been sent to the reporting host or
    realm.

Section 5.3, 6th paragraph:
Existing text:
    If the reacting node does not receive an OLR in messages sent to the
    formerly overloaded node then the reacting node SHOULD slowly
    increase the rate of traffic sent to the overloaded node.
Comment: confusing.
Proposal: Replace paragraph with:
    If the reacting node does not receive an OLR in response to messages
    sent to the formerly overloaded node then the reacting node SHOULD
    slowly increase the rate of traffic sent to the overloaded node.



--------------090602090608070107090008
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Ulrich,

    

    I support the suggested changes in your suggested changes 18, 19, 20
    and 21:

    

    
    
Section 4.3, 3rd paragraph:
Existing text:
   The extension MAY define new AVPs for use in DOIC Capability
   Announcement and for use in DOIC Overload reporting.  These new AVPs
   SHOULD be defined to be extensions to the OC-Supported-Features and
   OC-OLR AVPs defined in this document.
Comment: It is not necessary for a new AVP to be an extension to both the OC-Supported-Features AVP and the OC-OLR AVP.
Proposal: Replace the paragraph with:
   The extension MAY define new AVPs for use in DOIC Capability
   Announcement and for use in DOIC Overload reporting.  These new AVPs
   SHOULD be defined to be extensions to the OC-Supported-Features and/or
   OC-OLR AVPs defined in this document.

Section 5.1, 9th paragraph:
Existing text:
   4.  The reacting node determines if overload abatement treatment
       should be applied to the request.  One approach that could be
       taken for each request is to select a random number between 1 and
       100.  If the random number is less than the indicated reduction
       percentage then the request is given abatement treatment,
       otherwise the request is given normal routing treatment.
Comment:The maths is wrong.
Proposal: Replace the paragraph with:
   4.  The reacting node determines if overload abatement treatment
       should be applied to the request.  One approach that could be
       taken for each request is to select a random number between 1 and
       100.  If the random number is less than or equal to the indicated
       reduction percentage then the request is given abatement treatment,
       otherwise the request is given normal routing treatment.

Section 5.3, 4th paragraph:
Existing text:
   When applying overload abatement treatment for the load abatement
   algorithm, the reacting node MUST abate the requested percentage of
   requests that would have otherwise been sent to the reporting host or
   realm.
Comment: probably a typo.
Proposal: Replace the paragraph with:
   When applying overload abatement treatment for the loss abatement
   algorithm, the reacting node MUST abate the requested percentage of
   requests that would have otherwise been sent to the reporting host or
   realm.

Section 5.3, 6th paragraph:
Existing text:
   If the reacting node does not receive an OLR in messages sent to the
   formerly overloaded node then the reacting node SHOULD slowly
   increase the rate of traffic sent to the overloaded node.
Comment: confusing.
Proposal: Replace paragraph with:
   If the reacting node does not receive an OLR in response to messages
   sent to the formerly overloaded node then the reacting node SHOULD
   slowly increase the rate of traffic sent to the overloaded node.

    

  


--------------090602090608070107090008--


From nobody Tue Dec  9 06:23:33 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0A61A1BAA for ; Tue,  9 Dec 2014 06:23:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKF1Mz7-OLMK for ; Tue,  9 Dec 2014 06:23:30 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE2031A1AEA for ; Tue,  9 Dec 2014 06:23:29 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63051 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XyLhH-00097d-NB for dime@ietf.org; Tue, 09 Dec 2014 06:23:29 -0800
Message-ID: <548705DF.40102@usdonovans.com>
Date: Tue, 09 Dec 2014 08:23:27 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------050700040907000904020803"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/nr4jse4msGd6o6mWQg0kAokXmzw
Subject: [Dime] Ulrich's suggested changes 22 and 23
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 14:23:31 -0000

This is a multi-part message in MIME format.
--------------050700040907000904020803
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

For your changes 22 and 23:

Section 6.1, last paragraph:
Existing text:
    The OC-Feature-Vector sub-AVP is used to announce the DOIC features
    supported by the DOIC node, in the form of a flag-bits field in which
    each bit announces one feature or capability supported by the node
    (see Section 6.2).  The absence of the OC-Feature-Vector AVP
    indicates that only the default traffic abatement algorithm described
    in this specification is supported.
Comment: Absence of OC-Feature-Vector AVP indicates different things depending on the type of message (request / answer).
Proposal: Replace the paragraph with:
    The OC-Feature-Vector sub-AVP is used to announce the DOIC features
    supported by the DOIC node, in the form of a flag-bits field in which
    each bit announces one feature or capability supported by the node
    (see Section 6.2).  The absence of the OC-Feature-Vector AVP in request
    messages indicates that only the default traffic abatement algorithm
    described in this specification is supported. The absence of the OC-
    Feature-Vector AVP in answer messages indicates that the default
    traffic abatement algorithm described in this specification is selected
    (while other traffic abatement algorithms may be supported), and no
    features other than abatement algorithms are supported.

Section 6.2, 2nd paragraph:
Existing text:
    The OC-Feature-Vector sub-AVP is used to announce the DOIC features
    supported by the DOIC node, in the form of a flag-bits field in which
    each bit announces one feature or capability supported by the node
    (see Section 6.2).  The absence of the OC-Feature-Vector AVP
    indicates that only the default traffic abatement algorithm described
    in this specification is supported.
Comment: seems to be misplaced as reference is given to 6.2.
Proposal: remove the paragraph.



I support the wording change in #22 but suggest it be moved to section 
6.2, with the reference removed.  As a result, the paragraph should be 
removed from section 6.1 and changed in section 6.2 to the following 
(removing the reference):

    The OC-Feature-Vector sub-AVP is used to announce the DOIC features
    supported by the DOIC node, in the form of a flag-bits field in which
    each bit announces one feature or capability supported by the node.
    The absence of the OC-Feature-Vector AVP in request
    messages indicates that only the default traffic abatement algorithm
    described in this specification is supported. The absence of the OC-
    Feature-Vector AVP in answer messages indicates that the default
    traffic abatement algorithm described in this specification is selected
    (while other traffic abatement algorithms may be supported), and no
    features other than abatement algorithms are supported.

Regards,

Steve

--------------050700040907000904020803
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Ulrich,

    

    For your changes 22 and 23:

    

    
    
Section 6.1, last paragraph:
Existing text:
   The OC-Feature-Vector sub-AVP is used to announce the DOIC features
   supported by the DOIC node, in the form of a flag-bits field in which
   each bit announces one feature or capability supported by the node
   (see Section 6.2).  The absence of the OC-Feature-Vector AVP
   indicates that only the default traffic abatement algorithm described
   in this specification is supported.
Comment: Absence of OC-Feature-Vector AVP indicates different things depending on the type of message (request / answer).
Proposal: Replace the paragraph with:
   The OC-Feature-Vector sub-AVP is used to announce the DOIC features
   supported by the DOIC node, in the form of a flag-bits field in which
   each bit announces one feature or capability supported by the node
   (see Section 6.2).  The absence of the OC-Feature-Vector AVP in request
   messages indicates that only the default traffic abatement algorithm
   described in this specification is supported. The absence of the OC-
   Feature-Vector AVP in answer messages indicates that the default
   traffic abatement algorithm described in this specification is selected
   (while other traffic abatement algorithms may be supported), and no
   features other than abatement algorithms are supported.

Section 6.2, 2nd paragraph:
Existing text:
   The OC-Feature-Vector sub-AVP is used to announce the DOIC features
   supported by the DOIC node, in the form of a flag-bits field in which
   each bit announces one feature or capability supported by the node
   (see Section 6.2).  The absence of the OC-Feature-Vector AVP
   indicates that only the default traffic abatement algorithm described
   in this specification is supported.
Comment: seems to be misplaced as reference is given to 6.2.
Proposal: remove the paragraph.

    

    

    I support the wording change in #22 but suggest it be moved to
    section 6.2, with the reference removed.  As a result, the paragraph
    should be removed from section 6.1 and changed in section 6.2 to the
    following (removing the reference):

    

    
   The OC-Feature-Vector sub-AVP is used to announce the DOIC features
   supported by the DOIC node, in the form of a flag-bits field in which
   each bit announces one feature or capability supported by the node.
   The absence of the OC-Feature-Vector AVP in request
   messages indicates that only the default traffic abatement algorithm
   described in this specification is supported. The absence of the OC-
   Feature-Vector AVP in answer messages indicates that the default
   traffic abatement algorithm described in this specification is selected
   (while other traffic abatement algorithms may be supported), and no
   features other than abatement algorithms are supported.


    Regards,

    

    Steve

  


--------------050700040907000904020803--


From nobody Tue Dec  9 06:27:03 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1901A037E for ; Tue,  9 Dec 2014 06:27:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXD4dW6IE1wm for ; Tue,  9 Dec 2014 06:27:00 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92A81A0451 for ; Tue,  9 Dec 2014 06:27:00 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63056 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XyLkg-0000dd-IC for dime@ietf.org; Tue, 09 Dec 2014 06:27:00 -0800
Message-ID: <548706B2.70706@usdonovans.com>
Date: Tue, 09 Dec 2014 08:26:58 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------080808020601050004090109"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2chlmt8sxFuvNdMMkcW83j0ve9k
Subject: [Dime] Ulrich's suggested changes 24, 25 and 26
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 14:27:02 -0000

This is a multi-part message in MIME format.
--------------080808020601050004090109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

I support your suggested changes 24, 25 and 26:

Section 6.3, 1st paragraph:
Existing text:
    The OC-OLR AVP (AVP code TBD2) is of type Grouped and contains the
    information necessary to convey an overload report on an overload
    condition at the reporting node.  The OC-OLR AVP does not explicitly
    contain all information needed by the reacting node to decide whether
    a subsequent request must undergo abatement using the received
    reduction percentage.  The value of the OC-Report-Type AVP within the
    OC-OLR AVP indicates which implicit information is relevant for this
    decision (see Section 6.6).  The application the OC-OLR AVP applies
    to is the same as the Application-Id found in the Diameter message
    header.  The host or realm the OC-OLR AVP concerns is determined from
    the Origin-Host AVP and/or Origin-Realm AVP found in the
    encapsulating Diameter command.  The OC-OLR AVP is intended to be
    sent only by a reporting node.
Comment: Reduction percentage may not be used by all future algorithms.
Proposal: Replace the paragraph with:
    The OC-OLR AVP (AVP code TBD2) is of type Grouped and contains the
    information necessary to convey an overload report on an overload
    condition at the reporting node.  The OC-OLR AVP does not explicitly
    contain all information needed by the reacting node to decide whether
    a subsequent request must undergo abatement using the selected
    abatement algorithm.  The value of the OC-Report-Type AVP within the
    OC-OLR AVP indicates which implicit information is relevant for this
    decision (see Section 6.6).  The application the OC-OLR AVP applies
    to is the same as the Application-Id found in the Diameter message
    header.  The host or realm the OC-OLR AVP concerns is determined from
    the Origin-Host AVP and/or Origin-Realm AVP found in the
    encapsulating Diameter command.  The OC-OLR AVP is intended to be
    sent only by a reporting node.

Section 6.8, last character
Proposal: remove the "."

Section 8.2, last paragraph:
Existing text:
    See Section 6.2 for the initial assignment in the registry.  New
    types can be added using the Specification Required policy [RFC5226].
Comment: wrong reference.
Proposal: Replace the paragraph with:
    See Section 6.6 for the initial assignment in the registry.  New
    types can be added using the Specification Required policy [RFC5226].



--------------080808020601050004090109
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Ulrich,

    

    I support your suggested changes 24, 25 and 26:

    

    
    
Section 6.3, 1st paragraph:
Existing text:
   The OC-OLR AVP (AVP code TBD2) is of type Grouped and contains the
   information necessary to convey an overload report on an overload
   condition at the reporting node.  The OC-OLR AVP does not explicitly
   contain all information needed by the reacting node to decide whether
   a subsequent request must undergo abatement using the received
   reduction percentage.  The value of the OC-Report-Type AVP within the
   OC-OLR AVP indicates which implicit information is relevant for this
   decision (see Section 6.6).  The application the OC-OLR AVP applies
   to is the same as the Application-Id found in the Diameter message
   header.  The host or realm the OC-OLR AVP concerns is determined from
   the Origin-Host AVP and/or Origin-Realm AVP found in the
   encapsulating Diameter command.  The OC-OLR AVP is intended to be
   sent only by a reporting node.
Comment: Reduction percentage may not be used by all future algorithms.
Proposal: Replace the paragraph with:
   The OC-OLR AVP (AVP code TBD2) is of type Grouped and contains the
   information necessary to convey an overload report on an overload
   condition at the reporting node.  The OC-OLR AVP does not explicitly
   contain all information needed by the reacting node to decide whether
   a subsequent request must undergo abatement using the selected
   abatement algorithm.  The value of the OC-Report-Type AVP within the
   OC-OLR AVP indicates which implicit information is relevant for this
   decision (see Section 6.6).  The application the OC-OLR AVP applies
   to is the same as the Application-Id found in the Diameter message
   header.  The host or realm the OC-OLR AVP concerns is determined from
   the Origin-Host AVP and/or Origin-Realm AVP found in the
   encapsulating Diameter command.  The OC-OLR AVP is intended to be
   sent only by a reporting node.

Section 6.8, last character
Proposal: remove the "."

Section 8.2, last paragraph:
Existing text:
   See Section 6.2 for the initial assignment in the registry.  New
   types can be added using the Specification Required policy [RFC5226].
Comment: wrong reference.
Proposal: Replace the paragraph with:
   See Section 6.6 for the initial assignment in the registry.  New
   types can be added using the Specification Required policy [RFC5226].

    

  


--------------080808020601050004090109--


From nobody Tue Dec  9 06:30:52 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17C21A1B36 for ; Tue,  9 Dec 2014 06:30:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZgiUF-mhuox for ; Tue,  9 Dec 2014 06:30:49 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 460DD1A1BC4 for ; Tue,  9 Dec 2014 06:30:49 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sB9EUlVQ010506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Dec 2014 14:30:47 GMT
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sB9EUkLk015287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 15:30:47 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 15:30:46 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Ulrich suggested change number 3
Thread-Index: AQHQEzuyHw34kXDxv0iSafX1rpswJ5yHTSnA
Date: Tue, 9 Dec 2014 14:30:46 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815235158@DEMUMBX014.nsn-intra.net>
References: <54862F13.1060907@usdonovans.com>
In-Reply-To: <54862F13.1060907@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2826
X-purgate-ID: 151667::1418135447-0000677A-4B476211/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5SgqxjkwRL82YoialzTGJoj8HX4
Subject: Re: [Dime] Ulrich suggested change number 3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 14:30:51 -0000

Steve,

please see inline.

Ulrich


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 09, 2014 12:07 AM
To: dime@ietf.org
Subject: [Dime] Ulrich suggested change number 3

Ulrich,

For suggested change number 3:
Section 3.2, last two paragraphs:
Existing text:
   The DCA mechanism must also allow the scenario where the set of
   features supported by the sender of a request and by agents in the
   path of a request differ.  In this case, the agent updates the OC-
   Supported-Features AVP to reflect the mixture of the two sets of
   supported features.

      Note: The logic to determine the content of the modified  OC-
      Supported-Features AVP is out-of-scope for this specification and
      is left to implementation decisions.  Care must be taken not to
      introduce interoperability issues for downstream or upstream DOIC
      nodes.

Comment: It is perfectly ok (in this case) for the agent not to update and =
not to modify.=20

Proposal: It is proposed to replace the two paragraphs with the following:
   The DCA mechanism must also allow the scenario where the set of
   features supported by the sender of a request and by agents in the
   path of a request differ.  In this case, the agent can update the OC-
   Supported-Features AVP to reflect the mixture of the two sets of
   supported features.

      Note: The logic to determine whether and if how to modify the
      content of the OC-Supported-Features AVP is out-of-scope for this
      specification and is left to implementation decisions.  Care must
      be taken not to introduce interoperability issues for downstream
      or upstream DOIC nodes.
I don't see the need for the change as the paragraph is talking specificall=
y about the scenario where an agent would change the OC-Supported-Features =
AVP.
 I do not agree. The paragraph is talking specifically about the ca=
se where the set of features supported by the sender of a request and by ag=
ents in the path of a request differ. In this case it is certainly true tha=
t the agent can update (modify, change) the OC-Supported-Features AVP. It i=
s, however, also true that in this case the agent can choose not to update.=
=20
That said, the change in the first paragraph is ok.
 thank you 
If we make that change then I suggest a cleaned up first sentence of the ne=
xt paragraph as follows:

"Note: The logic to determine if the content of the=A0 OC-Supported-Feature=
s AVP should be changed is out-of-scope for this document, as is the logic =
to determine the content of a modified OC-Supported-Features AVP.=A0 These =
are left to implementation decisions..."
 The clean up is fine

Regards,

Steve


From nobody Tue Dec  9 06:35:44 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C621A7008 for ; Tue,  9 Dec 2014 06:35:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Cow8RhZJlyB for ; Tue,  9 Dec 2014 06:35:41 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D1F1A7003 for ; Tue,  9 Dec 2014 06:35:41 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sB9EZdJ4001109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Dec 2014 14:35:39 GMT
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sB9EZccW003302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 15:35:38 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 15:35:37 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Ulrich's suggested change #7
Thread-Index: AQHQE7D4su+J0E8dP06NBQiCcm0fbpyHUrVg
Date: Tue, 9 Dec 2014 14:35:37 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815235171@DEMUMBX014.nsn-intra.net>
References: <5486F3D7.7040305@usdonovans.com>
In-Reply-To: <5486F3D7.7040305@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1019
X-purgate-ID: 151667::1418135739-0000658F-5916AE59/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/73o8yrE11EvzUkhTok0wLqGfco4
Subject: Re: [Dime] Ulrich's suggested change #7
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 14:35:43 -0000

Steve,

please see inline.

Ulrich


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 09, 2014 2:07 PM
To: dime@ietf.org
Subject: [Dime] Ulrich's suggested change #7

Ulrich,

For your suggested change #7:
Section 4.1.2, 4th paragraph:
Existing text:
   A reporting node knows what overload control functionality is
   supported by the reacting node based on the content of the OC-
   Feature-Vector AVP in the request message.
Comment: The Feature-Vector AVP may be absent. In this case knowledge canno=
t be based on the content.
Proposal: Replace the paragraph with:
   A reporting node knows what overload control functionality is
   supported by the reacting node based on the content or absence of
   the OC-Feature-Vector AVP within the Supported-Features AVP in the
   request message.
I support the change with the modification of Supported-Features to OC-Supp=
orted-Features.
 fine with me

Regards,

Steve


From nobody Tue Dec  9 07:30:53 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418731A8733 for ; Tue,  9 Dec 2014 07:30:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQAgLex-lJkk for ; Tue,  9 Dec 2014 07:30:40 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79B91A1C00 for ; Tue,  9 Dec 2014 07:30:39 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sB9FUc9q009491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Dec 2014 15:30:38 GMT
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sB9FUZUn018635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 16:30:38 +0100
Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Dec 2014 16:30:35 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 16:30:35 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Ulrich's suggested change #8
Thread-Index: AQHQE7IIHC1/0vM3HEqfMpUtT/PrYZyHWeWw
Date: Tue, 9 Dec 2014 15:30:35 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815235197@DEMUMBX014.nsn-intra.net>
References: <5486F59E.4000908@usdonovans.com>
In-Reply-To: <5486F59E.4000908@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1947
X-purgate-ID: 151667::1418139038-0000658F-0A4E8594/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/vgjGfYpgxtv0eOAACfOduno5ZSQ
Subject: Re: [Dime] Ulrich's suggested change #8
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 15:30:43 -0000

Steve,

please see inline.

Ulrich


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 09, 2014 2:14 PM
To: dime@ietf.org
Subject: [Dime] Ulrich's suggested change #8

Ulrich,

For your suggested change number 8:
Section 4.1.2, 8th paragraph:
Existing text:
   For an ongoing overload condition, a reporting node MUST NOT change
   the selected algorithm during the period of time that it is in an
   overload condition and, as a result, is sending OC-OLR AVPs in answer
   messages.

Comment: As a result of an ongoing overload condition the reporting node is=
=20
sending OC-OLR AVPs containing no validity duration or a validity duration=
=20
different from zero in answer messages.

Proposal: Replace the paragraph with:
   For an ongoing overload condition, a reporting node MUST NOT change
   the selected algorithm during the period of time that it is in an
   overload condition and, as a result, is sending OC-OLR AVPs
   containing no validity duration or a validity duration different
   from zero in answer messages.
I don't see the need for the change.=A0 The selected algorithm should not c=
hange for all overload reports relating to an overload condition, including=
 overload reports with a validity duration of zero.
 Isn't it so that when the overload condition ends (i.e. is no long=
er ongoing), the reporting node starts sending OLRs with validity duration =
of zero (for a long enough period of time)? (see end of section 4.2.1.4)=20
The question now is whether the change of algorithm is allowed during this =
(long enough) period, or only after that period. I don't have a strong view=
. But this was not my point.
My point is that the current text seems to suggest that an overload conditi=
on is ongoing as long as OC-OLR AVPs are sent in answer messages, and I thi=
nk that is not true. 

Regards,

Steve


From nobody Tue Dec  9 07:39:44 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46DD1A19FE for ; Tue,  9 Dec 2014 07:39:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOv7YxGO385E for ; Tue,  9 Dec 2014 07:39:36 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAA361A03B3 for ; Tue,  9 Dec 2014 07:39:35 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sB9FdX3p031436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Dec 2014 15:39:33 GMT
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sB9FdXEF019101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 16:39:33 +0100
Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Dec 2014 16:39:33 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 16:39:33 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Ulrich's suggested changes #9 and #10
Thread-Index: AQHQE7T7vuqzLdFcQkSln68uxDBIDZyHZFxQ
Date: Tue, 9 Dec 2014 15:39:32 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668152351AC@DEMUMBX014.nsn-intra.net>
References: <5486FA8B.6040503@usdonovans.com>
In-Reply-To: <5486FA8B.6040503@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 3355
X-purgate-ID: 151667::1418139573-0000658F-383F6AEB/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dYBkLtVi-dLDwwlrymLS3LC9I2g
Subject: Re: [Dime] Ulrich's suggested changes #9 and #10
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 15:39:43 -0000

Steve,
I agree with your suggestions.

Ulrich


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 09, 2014 2:35 PM
To: dime@ietf.org
Subject: [Dime] Ulrich's suggested changes #9 and #10

Ulrich,

Suggested changes 9 and 10 are linked so I'll deal with them in a single em=
ail:
Section 4.1.3, 1st paragraph:
Existing text:
   Diameter Agents that support DOIC SHOULD ensure that all messages
   relayed by the agent contain the OC-Supported-Features AVP.
Comment: The SHOULD in the first line is not correct based on my next comme=
nt.
Proposal: Delete the first paragraph.=20

Section 4.1.3, 4th paragraph:
Existing text:
   A Diameter Agent SHOULD take on reporting node behavior for Diameter
   endpoints that do not support the DOIC solution.  A Diameter Agent
   detects that a Diameter endpoint does not support DOIC reporting node
   behavior when there is no OC-Supported-Features AVP in an answer
   message for a transaction that contained the OC-Supported-Features
   AVP in the request message.
Comment: The first sentence can reasonably only apply to Diameter agents th=
at are immediate peers to the non-supporting Diameter endpoint. We cannot e=
xpect a far-away-agent to take on reporting node behavior when all upstream=
 agents and the server do not support DOIC. Furthermore: When the non-suppo=
rting server has two DOIC supporting immediate peer agents which both take =
on reporting node behavior we end up in problems similar to those identifie=
d in the note in section 3.3.
Proposal:Replace the paragaph with:
   A Diameter Agent that is an immediate peer to the Diameter endpoint
   that does not support DOIC SHOULD take on reporting node behavior for
   Diameter endpoints that do not support the DOIC solution.  A Diameter
   Agent detects that a Diameter endpoint does not support DOIC reporting
   node behavior when there is no OC-Supported-Features AVP in an answer
   message for a transaction that contained the OC-Supported-Features
   AVP in the request message.
      Note: Known issues exist if multiple sources for overload reports
      which apply to the same Diameter entity exist.  Reacting nodes
      have no way of determining the source and, as such, will treat
      them as coming from a single source.  Variance in sequence numbers
      between the two sources can then cause incorrect overload
      abatement treatment to be applied for indeterminate periods of
      time.
You point out an interesting issue with agents taking on reporting node fun=
ctionality.

I don't, however, think that an agent that takes on reporting node function=
ality for a non supporting host needs to be adjacent to the host.=A0 The im=
portant thing is that it has visibility to all of the traffic sent to the h=
ost.

I suggest keeping the first paragraph but changing the SHOULD to a MAY.

I also suggest changing the SHOULD to a MAY in the fourth paragraph and cha=
nging the first sentence to:

A Diameter Agent MAY take on reporting node behavior for Diameter endpoints=
 that do not support the DOIC solution.=A0 The Diameter Agent MUST have vis=
ibility to all traffic destined for the non supporting host in order to bec=
ome the reporting node for the Diameter endpoint.

Regards,

Steve


From nobody Tue Dec  9 08:47:06 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6561A8960 for ; Tue,  9 Dec 2014 08:47:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k21cENLdtbW6 for ; Tue,  9 Dec 2014 08:47:00 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFF561A888F for ; Tue,  9 Dec 2014 08:46:59 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sB9Gkv0G005352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Dec 2014 16:46:57 GMT
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sB9GktFn004376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 17:46:57 +0100
Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Dec 2014 17:46:55 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 17:46:54 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Ulrich's suggested change @12
Thread-Index: AQHQE7ZHD23zRsD0mUyK0fJgC7jhrJyHbHpA
Date: Tue, 9 Dec 2014 16:46:54 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668152351D9@DEMUMBX014.nsn-intra.net>
References: <5486FCBF.4000707@usdonovans.com>
In-Reply-To: <5486FCBF.4000707@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668152351D9DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 9653
X-purgate-ID: 151667::1418143617-0000677A-32D29B6A/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/cpWHBFSEU0jnxlUTjiLqgG4oCII
Subject: Re: [Dime] Ulrich's suggested change @12
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 16:47:03 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668152351D9DEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,

I agree, my comment and proposal do not hit the mark.



The intention was to say that known issues exist if there are multiple agen=
ts on multiple paths between client and server. The agents may not be able =
to ensure that there is no ambiguity in DOIC behaviour for the client. E.g.=
 from the client's point of view the answer to a first request (which was m=
odified by agent A1) could indicate: DOIC is supported, currenty no overloa=
d, once in overload loss will be selected; and the answer to the next reque=
st (which was modified by agent A2) could indicate: DOIC is supported, some=
?? reduction is requested using rate. The client, however, may not be prepa=
red for rate.



Maybe a warning note could be added to say that the agent may not always be=
 able to ensure that there is no ambiguity.



Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 09, 2014 2:45 PM
To: dime@ietf.org
Subject: [Dime] Ulrich's suggested change @12

Ulrich,

For your suggested change #12:

Section 4.1.3, last paragraph:

Existing text:

   When making changes to the OC-Supported-Features AVP the Diameter

   Agent needs to ensure that there is no ambiguity in DOIC behavior for

   both upstream and downstream DOIC nodes.



Comment: while that is true, in addition problems similar to those

identified in the note in section 3.3 may result from making changes.



Proposal: Add the note:

      Note: Known issues exist if multiple sources for overload reports

      which apply to the same Diameter entity exist.  Reacting nodes

      have no way of determining the source and, as such, will treat

      them as coming from a single source.  Variance in sequence numbers

      between the two sources can then cause incorrect overload

      abatement treatment to be applied for indeterminate periods of

      time.
I don't understand how these are related.  The change to the OC-Supported-F=
eatures AVP made by the agent apply only to the transaction.  In addition, =
this paragraph doesn't mention overload reports.

Regards,

Steve


--_000_5BCBA1FC2B7F0B4C9D935572D9000668152351D9DEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,


I agree, my comment and prop=
osal do not hit the mark.


 


The intention was to say tha=
t known issues exist if there are multiple agents on multiple paths between=
 client and server. The agents may not be able to ensure that there is no a=
mbiguity in DOIC behaviour for the client.
 E.g. from the client’s point of view the answer to a first request (=
which was modified by agent A1) could indicate: DOIC is supported, currenty=
 no overload, once in overload loss will be selected; and the answer to the=
 next request (which was modified by agent
 A2) could indicate: DOIC is supported, some?? reduction is requested using=
 rate. The client, however, may not be prepared for rate.=



 


Maybe a warning note could b=
e added to say that the agent may not always be able to ensure that there i=
s no ambiguity.


 


Ulrich


 =
;


 =
;


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Tuesday, December 09, 2014 2:45 PM

To: dime@ietf.org

Subject: [Dime] Ulrich's suggested change @12






 


Ulrich,



For your suggested change #12:


Section 4.1.3, last paragraph:


Existing text:


   When making changes to the OC-Supported-Features AVP the =
Diameter


   Agent needs to ensure that there is no ambiguity in DOIC =
behavior for


   both upstream and downstream DOIC nodes.


 


Comment: while that is true, in addition problems similar to those 


identified in the note in section 3.3 may result from making changes.<=
o:p>


 


Proposal: Add the note:


      Note: Known issues exist if multiple so=
urces for overload reports


      which apply to the same Diameter entity=
 exist.  Reacting nodes


      have no way of determining the source a=
nd, as such, will treat


      them as coming from a single source.&nb=
sp; Variance in sequence numbers


      between the two sources can then cause =
incorrect overload


      abatement treatment to be applied for i=
ndeterminate periods of


      time.


I don't understand ho=
w these are related.  The change to the OC-Supported-Features AVP made=
 by the agent apply only to the transaction.  In addition, this paragr=
aph doesn't mention overload reports.



Regards,



Steve










--_000_5BCBA1FC2B7F0B4C9D935572D9000668152351D9DEMUMBX014nsnin_--


From nobody Tue Dec  9 09:04:59 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE0B1A1A22 for ; Tue,  9 Dec 2014 09:04:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Be2-iM5rrTZq for ; Tue,  9 Dec 2014 09:04:53 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4A81A09CF for ; Tue,  9 Dec 2014 09:04:52 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sB9H4plk007224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Dec 2014 17:04:51 GMT
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sB9H4oI0013141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 18:04:50 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 18:04:50 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Ulrich's suggested change #15
Thread-Index: AQHQE7dJhQB5e1nbwEev114RSsJu35yHeSWg
Date: Tue, 9 Dec 2014 17:04:50 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815235215@DEMUMBX014.nsn-intra.net>
References: <5486FE71.70205@usdonovans.com>
In-Reply-To: <5486FE71.70205@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1396
X-purgate-ID: 151667::1418144691-0000677A-CE6A3457/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/zDHuuKc7aQQX5QQuF9mnkAytxGY
Subject: Re: [Dime] Ulrich's suggested change #15
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 17:04:55 -0000

Hi Steve,

I think it was pointed out by Ben that we do not specify behaviour of a nod=
e for cases where it detects that another node is breaking the rule.
The rule is:
   A reporting node MUST NOT send overload reports of a type that has
   not been advertised as supported by the reacting node.
See section 4.2.3.

Regards
Ulrich

 =20

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 09, 2014 2:52 PM
To: dime@ietf.org
Subject: [Dime] Ulrich's suggested change #15

Ulrich,

For your suggested change #15:
Section 4.2.1.3, 4th paragraph:
Existing text:
   When receiving an OC-OLR AVPs with unknown values, a reacting node
   SHOULD be silently discarded by reacting nodes and the event SHOULD
   be logged.
Comment: text is confusing. Maybe the intention was to say:
   When receiving an OC-OLR AVPs with an unsupported report type value, a r=
eacting node
   SHOULD silently discarded the OC-OLR AVP and the event SHOULD
   be logged.
But even that is not correct.
Proposal: Remove the paragraph.
The intent was that an OC-OLR that contains unknown values should be discar=
ded.=A0 I agree that the wording needs to be changes as you suggested.=A0 I=
 don't agree with removing the paragraph.=A0 Can you elaborate on why you t=
hink it is not correct when changed as you suggested?

Regards,

Steve


From nobody Tue Dec  9 09:30:03 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0384F1A8986 for ; Tue,  9 Dec 2014 09:30:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukvQHLF1spdO for ; Tue,  9 Dec 2014 09:29:56 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 802E71A88DD for ; Tue,  9 Dec 2014 09:29:55 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sB9HTrdl018402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Dec 2014 17:29:53 GMT
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sB9HTqKL032257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 18:29:53 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Dec 2014 18:29:52 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 18:29:52 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Ulrich's suggested change #16
Thread-Index: AQHQE7lXyc+G3J0M1EW8kbPFxFEQNZyHfq1Q
Date: Tue, 9 Dec 2014 17:29:51 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815235234@DEMUMBX014.nsn-intra.net>
References: <548701E1.3060502@usdonovans.com>
In-Reply-To: <548701E1.3060502@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2820
X-purgate-ID: 151667::1418146193-0000677A-08D434AC/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kKye2MN6cF0ppqSSWZSChQapMFI
Subject: Re: [Dime] Ulrich's suggested change #16
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 17:30:01 -0000

Steve,
yes, then, maybe, the definition of Diversion is not correct?
What are other people's views?

My assumption was:
If a host is overloaded, it does not help to direct traffic to that host vi=
a a different path.
If a realm is overloaded, it does not help to direct traffic to that realm =
via a different path.
If a host is overloaded, it helps to select an alternative (not overloaded)=
 host (if possible) and direct traffic to that host.
If a realm is overloaded, there never is an alternative (not overloaded) re=
alm to which traffic could be directed.

With the current definition of Diversion, Diversion is no appropriate means=
 to address host overload and is no appropriate means to address realm over=
load. It may be ok for agent overload only.

Regards
Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 09, 2014 3:06 PM
To: dime@ietf.org
Subject: [Dime] Ulrich's suggested change #16

Ulrich,

For your suggested change #16:
Section 4.2.2, 5th and 6th paragraph:
Existing text:
   If the request is a host-routed request then the reacting node SHOULD
   apply throttling abatement treatment to the request.
=20
   If the request is a realm-routed request then the reacting node
   SHOULD apply diversion abatement treatment to the request.

Comment: I don't think so. If the reacting node selects the server and=20
then detects that the selected server is overloaded and then detects that=20
the request does not survive (i.e. is subject to abatement), then the react=
ing=20
node SHOULD apply diversion treatment (i.e. select an alternative server if=
 possible).=20
If the reacting node does not select the server (either a. because the serv=
er was=20
already selected by a downstream node, or b. because the server will be sel=
ected=20
by an upstream node) then there is no point in applying diversion and the r=
eacting=20
node SHOULD apply throttling of requests that do not survive.

Proposal: replace the paragraphs with:
   If the reacting node does not select the server then it SHOULD apply
   throttling abatement to the request.

   If the reacting node selects the server then it SHOULD apply diversion
   abatement treatment (i.e. select an alternative server if possible) to
   the request.
Diversion is not selecting an alternative node to handle the request.=A0 Di=
version is selecting an alternative route to the selected node.=A0=20

Whether it is appropriate to select an alternative node for a request is an=
 application decision that probably changes on a per command-code basis wit=
hin the application.=A0 Logic like this is outside the scope of the DOIC sp=
ecification.

The text is correct based on the definition of diversion.

Regards,

Steve


From nobody Tue Dec  9 09:32:22 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3819E1A899C for ; Tue,  9 Dec 2014 09:32:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 785wwLY8i_Rh for ; Tue,  9 Dec 2014 09:32:18 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FDED1A897E for ; Tue,  9 Dec 2014 09:32:18 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sB9HWGnQ022632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Dec 2014 17:32:16 GMT
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sB9HWGRZ003203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 18:32:16 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 18:32:16 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Ulrich's suggested change #17
Thread-Index: AQHQE7nkAgYKgsAcYUGaff72Vzht6pyHhJEA
Date: Tue, 9 Dec 2014 17:32:16 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815235248@DEMUMBX014.nsn-intra.net>
References: <548702B4.3070806@usdonovans.com>
In-Reply-To: <548702B4.3070806@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1483
X-purgate-ID: 151667::1418146336-0000677A-8928D061/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Qz87AT3m3AeiXWRYIhKOfzVA7eo
Subject: Re: [Dime] Ulrich's suggested change #17
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 17:32:20 -0000

Steve,

I agree.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 09, 2014 3:10 PM
To: dime@ietf.org
Subject: [Dime] Ulrich's suggested change #17

Ulrich,

For your suggested change #17:
Section 4.2.2, last paragraph:
Existing text:
   In the case that the OCS entry indicated no traffic was to be sent to
   the overloaded entity and the validity duration expires or has a
   validity duration of zero ("0"), meaning that the reporting node has
   explicitly signaled the end of the overload condition then overload
   abatement associated with the overload abatement MUST be ended in a
   controlled fashion.
Comment: If no traffic is sent, no OLR will be received, hence you cannot c=
ome out of a 100% throttling by explicit indication.
Proposal: replace the paragraph with:
   In the case that the OCS entry indicated no traffic was to be sent to
   the overloaded entity and the validity duration expires then overload
   abatement associated with the overload abatement MUST be ended in a
   controlled fashion.
I agree with the change with one additional modification - change the last =
abatement to report to make it:
   In the case that the OCS entry indicated no traffic was to be sent to
   the overloaded entity and the validity duration expires then overload
   abatement associated with the overload report MUST be ended in a
   controlled fashion.
Regards,

Steve




From nobody Tue Dec  9 09:38:25 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A4D1A8A3C for ; Tue,  9 Dec 2014 09:38:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uJwLZOSYdmV for ; Tue,  9 Dec 2014 09:38:22 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89821A8A0B for ; Tue,  9 Dec 2014 09:38:21 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sB9HcKt4032397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Dec 2014 17:38:20 GMT
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sB9HcJPV012030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 18:38:19 +0100
Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Dec 2014 18:38:19 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 18:38:19 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Ulrich's suggested changes 22 and 23
Thread-Index: AQHQE7u4hKYu0ZpjaUmm3zWsLOmME5yHhjkg
Date: Tue, 9 Dec 2014 17:38:19 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681523525E@DEMUMBX014.nsn-intra.net>
References: <548705DF.40102@usdonovans.com>
In-Reply-To: <548705DF.40102@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 3102
X-purgate-ID: 151667::1418146700-0000677A-15CEFDBF/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/IL4dtJZ3OikHrc4BoAB4VoJ9kOM
Subject: Re: [Dime] Ulrich's suggested changes 22 and 23
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Dec 2014 17:38:23 -0000

Steve,

I agree.

Regards
Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 09, 2014 3:23 PM
To: dime@ietf.org
Subject: [Dime] Ulrich's suggested changes 22 and 23

Ulrich,

For your changes 22 and 23:
Section 6.1, last paragraph:
Existing text:
   The OC-Feature-Vector sub-AVP is used to announce the DOIC features
   supported by the DOIC node, in the form of a flag-bits field in which
   each bit announces one feature or capability supported by the node
   (see Section 6.2).  The absence of the OC-Feature-Vector AVP
   indicates that only the default traffic abatement algorithm described
   in this specification is supported.
Comment: Absence of OC-Feature-Vector AVP indicates different things depend=
ing on the type of message (request / answer).
Proposal: Replace the paragraph with:
   The OC-Feature-Vector sub-AVP is used to announce the DOIC features
   supported by the DOIC node, in the form of a flag-bits field in which
   each bit announces one feature or capability supported by the node
   (see Section 6.2).  The absence of the OC-Feature-Vector AVP in request
   messages indicates that only the default traffic abatement algorithm
   described in this specification is supported. The absence of the OC-
   Feature-Vector AVP in answer messages indicates that the default
   traffic abatement algorithm described in this specification is selected
   (while other traffic abatement algorithms may be supported), and no
   features other than abatement algorithms are supported.

Section 6.2, 2nd paragraph:
Existing text:
   The OC-Feature-Vector sub-AVP is used to announce the DOIC features
   supported by the DOIC node, in the form of a flag-bits field in which
   each bit announces one feature or capability supported by the node
   (see Section 6.2).  The absence of the OC-Feature-Vector AVP
   indicates that only the default traffic abatement algorithm described
   in this specification is supported.
Comment: seems to be misplaced as reference is given to 6.2.
Proposal: remove the paragraph.


I support the wording change in #22 but suggest it be moved to section 6.2,=
 with the reference removed.=A0 As a result, the paragraph should be remove=
d from section 6.1 and changed in section 6.2 to the following (removing th=
e reference):
   The OC-Feature-Vector sub-AVP is used to announce the DOIC features
   supported by the DOIC node, in the form of a flag-bits field in which
   each bit announces one feature or capability supported by the node.
   The absence of the OC-Feature-Vector AVP in request
   messages indicates that only the default traffic abatement algorithm
   described in this specification is supported. The absence of the OC-
   Feature-Vector AVP in answer messages indicates that the default
   traffic abatement algorithm described in this specification is selected
   (while other traffic abatement algorithms may be supported), and no
   features other than abatement algorithms are supported.
Regards,

Steve


From nobody Wed Dec 10 04:29:54 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D471A88C8 for ; Wed, 10 Dec 2014 04:29:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfi15uKcXVuo for ; Wed, 10 Dec 2014 04:29:51 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85EA31A8890 for ; Wed, 10 Dec 2014 04:29:51 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50072 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XygOo-0002Pw-Ug; Wed, 10 Dec 2014 04:29:50 -0800
Message-ID: <54883CBA.7060503@usdonovans.com>
Date: Wed, 10 Dec 2014 06:29:46 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <54862C38.1000403@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152350CF@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668152350CF@DEMUMBX014.nsn-intra.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qvKtgT92wuZuGEw443lvqeMpkCM
Subject: Re: [Dime] Ulrich suggested change number 1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 12:29:52 -0000

Ulrich,

I think I see the source of confusion.  It is meant to talk about 
sending to adjacent DOIC nodes but it uses the words reacting and 
reporting nodes.  I suggest changing the paragraph to the following, 
removing the concept of reporting and reacting nodes from the description.

    While a DOIC node sends OLRs to "adjacent" DOIC nodes, nodes
    that are "adjacent" for DOIC purposes may not be adjacent from a
    Diameter, or transport, perspective.  For example, one or more
    Diameter agents that do not support DOIC may exist between a given
    pair of DOIC nodes, as long as those agents pass
    unknown AVPs through unchanged.  The report types described in this
    document can safely pass through non-supporting agents.  This may not
    be true for report types defined in future specifications.

Regards,

Steve

On 12/9/14, 7:16 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
>
> please see inline.
>
> Ulrich
>
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
> Sent: Monday, December 08, 2014 11:55 PM
> To: dime@ietf.org
> Subject: [Dime] Ulrich suggested change number 1
>
> Ulrich,
>
> I'll deal with each of your suggestion in a separate email to help ensure that nothing is missed.
>
> For your first suggestion:
> Section 3, last paragraph:
> Existing text:
>     While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
>     that are "adjacent" for DOIC purposes may not be adjacent from a
>     Diameter, or transport, perspective.  For example, one or more
>     Diameter agents that do not support DOIC may exist between a given
>     pair of reporting and reacting nodes, as long as those agents pass
>     unknown AVPs through unchanged.  The report types described in this
>     document can safely pass through non-supporting agents.  This may not
>     be true for report types defined in future specifications.
>
> Comment: while this is all not wrong, the existing text may convey the erring
> impression that there cannot be a DOIC supporting agent on the path between a
> reporting node and an adjacent reacting node.
>
> Proposal: It is proposed to add the following sentence at the end of the paragraph:
>     Another example is where one or more Diameter agents that do support
>     DOIC may exist between a given pair of reporting and reacting nodes,
>     as long as those agents pass OC-specific AVPs through unchanged.
> I don't agree with the suggested change, as the DOIC supporting agents might need to change the OC-specific AVPs.
>  I agree that in some cases DOIC supporting agents need to change the OC-specific AVPs. However, there are also cases where DOIC supporting agents do not need to change OC-specific AVPs.
>    I also don't understand how the paragraph implies that there cannot be DOIC supporting agents in the path of the request.
>  It does not imply that. Rather it may convey the erring impression that there cannot be a DOIC supporting agent on the path between a
> reporting node and an adjacent reacting node.
>     It is talking specifically about the case where there agents do not support DOIC are in the path.
>  No, my understanding is that the paragraph is talking specifically about what "adjacent for DOIC purposes" means. One valid example is given (reporting node and reacting node are "adjacent for DOIC purposes" if one or more agents that do not support DOIC but pass unsupported AVPs through unchanged exist between reporting node and reacting node) and I do not propose to remove that. However, there is another important valid example (reporting node and reacting node are "adjacent for DOIC purposes" if one or more DOIC supporting agents that pass OC-specific AVPs through unchanged exist between reporting node and reacting node), and the proposal is to add text to cover this example. 
> The remainder of the document makes it clear that there can be agents that do support DOIC in the path of a transaction.
>  that is not my point. The point is to clearly state that there can be DOIC supporting agents that pass through OC-specific AVPs unchanged on the path between reporting node and reacting node, and in this case the reporting and reacting nodes are still regarded "adjacent for DOIC purposes".
>
> I don't see the need for a change here.
>  I'm not proposing a modification but an addition. This addition provides useful clarification and in no way is harmful
>
> Regards,
>
> Steve
>


From nobody Wed Dec 10 04:34:30 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29521A1A81 for ; Wed, 10 Dec 2014 04:34:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.778
X-Spam-Level: 
X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1OEzsM1xFMr for ; Wed, 10 Dec 2014 04:34:27 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D856A1A870D for ; Wed, 10 Dec 2014 04:34:26 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50090 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XygT5-0006de-1A; Wed, 10 Dec 2014 04:34:26 -0800
Message-ID: <54883DC2.20504@usdonovans.com>
Date: Wed, 10 Dec 2014 06:34:10 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <54862D14.2060304@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235122@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815235122@DEMUMBX014.nsn-intra.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/grnZDirj2c71LT6OU3uIVObEymk
Subject: Re: [Dime] Ulrich suggested change number 2
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 12:34:28 -0000

Ulrich,

How about changing the last sentence to:

"This ensures that there is at least one commonly supported overload 
abatement algorithm supported by all DOIC nodes in the path of the request."

Regards,

Steve

On 12/9/14, 8:08 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
>
> please see inline.
>
> Ulrich
>
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
> Sent: Monday, December 08, 2014 11:58 PM
> To: dime@ietf.org
> Subject: [Dime] Ulrich suggested change number 2
>
> Ulrich,
>
> For the second suggested change:
> Section 3.2, 6th paragraph:
> Existing text:
>     The OC-Feature-Vector AVP will contain an indication of support for
>     the loss overload abatement algorithm defined in this specification
>     (see Section 5).  This ensures that there is at least one commonly
>     supported overload abatement algorithm between the reporting node and
>     the reacting node(s) in the path of the request.
>
> Comment: I agree that within a given path between client and server there may
> be more than one reacting nodes. But a given reporting node on that path does
> not have more than one adjacent reacting nodes on that given path to which it
> sends OLRs. I don't say that the existing text is wrong, but it is misleading.
> What we want to say here is that any given pair of adjacent reacting and reporting
> nodes will have at least one commonly supported algorithm.
>
> Proposal: It is proposed to replace the last line of the paragraph with:
>     The adjacent reacting node on the path of the request.
> It's more than just about the adjacent reaction nodes.  It is important that all reacting nodes in the path of the request have at least one common abatement algorithm.
> I do not agree. It is important that a pair of two adjacent reacting and reporting nodes (A,S) have at least one commonly supported algorithm, so that the reporting node can always select an algorithm supported by the adjacent reacting node. There may be another (non-adjacent) reacting node in the path (C), but its not important for C and S (which are not adjacent) to have a commonly supported algorithm.
> C---A---S
> It is important that C and A have a commonly supported algorith, as C and A are adjacent;
> It is important that A and S have a commonly supported algorith, as A and S are adjacent;
> It is true but not important (and nothing that needs to be ensured) that C and S have a commonly supported algorithm (indeed S could eventually select an algorithm not supported by C);
> It is true but not important that C, A and S have a commonly supported algorithm.
>
> I don't see the need for the suggested change.
>
> Regards,
>
> Steve
>


From nobody Wed Dec 10 04:41:06 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549B41A896F for ; Wed, 10 Dec 2014 04:41:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcXW1i6Wv2_Q for ; Wed, 10 Dec 2014 04:41:03 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DA3A1A88D3 for ; Wed, 10 Dec 2014 04:41:03 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50109 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XygZg-0000We-Sq; Wed, 10 Dec 2014 04:41:03 -0800
Message-ID: <54883F5C.1060603@usdonovans.com>
Date: Wed, 10 Dec 2014 06:41:00 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <5486FCBF.4000707@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152351D9@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668152351D9@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------060405030408090602050005"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/QdRbz-0Gs0GlHtdm-uig9t5QLEg
Subject: Re: [Dime] Ulrich's suggested change @12
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 12:41:05 -0000

This is a multi-part message in MIME format.
--------------060405030408090602050005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

This paragraph is talking about capability announcement.  We deal with 
the issues related to multiple sources of overload reports already 
elsewhere in the document.

I still do see the need for a change.

Steve

On 12/9/14, 10:46 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
> I agree, my comment and proposal do not hit the mark.
>
> The intention was to say that known issues exist if there are multiple 
> agents on multiple paths between client and server. The agents may not 
> be able to ensure that there is no ambiguity in DOIC behaviour for the 
> client. E.g. from the client's point of view the answer to a first 
> request (which was modified by agent A1) could indicate: DOIC is 
> supported, currenty no overload, once in overload loss will be 
> selected; and the answer to the next request (which was modified by 
> agent A2) could indicate: DOIC is supported, some?? reduction is 
> requested using rate. The client, however, may not be prepared for rate.
>
> Maybe a warning note could be added to say that the agent may not 
> always be able to ensure that there is no ambiguity.
>
> Ulrich
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Steve 
> Donovan
> *Sent:* Tuesday, December 09, 2014 2:45 PM
> *To:* dime@ietf.org
> *Subject:* [Dime] Ulrich's suggested change @12
>
> Ulrich,
>
> For your suggested change #12:
>
> Section 4.1.3, last paragraph:
> Existing text:
>     When making changes to the OC-Supported-Features AVP the Diameter
>     Agent needs to ensure that there is no ambiguity in DOIC behavior for
>     both upstream and downstream DOIC nodes.
>   
> Comment: while that is true, in addition problems similar to those
> identified in the note in section 3.3 may result from making changes.
>   
> Proposal: Add the note:
>        Note: Known issues exist if multiple sources for overload reports
>        which apply to the same Diameter entity exist.  Reacting nodes
>        have no way of determining the source and, as such, will treat
>        them as coming from a single source.  Variance in sequence numbers
>        between the two sources can then cause incorrect overload
>        abatement treatment to be applied for indeterminate periods of
>        time.
>
> I don't understand how these are related.  The change to the 
> OC-Supported-Features AVP made by the agent apply only to the 
> transaction.  In addition, this paragraph doesn't mention overload 
> reports.
>
> Regards,
>
> Steve
>


--------------060405030408090602050005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

    

    This paragraph is talking about capability announcement.  We deal
    with the issues related to multiple sources of overload reports
    already elsewhere in the document.

    

    I still do see the need for a change.

    

    Steve

    

    
On 12/9/14, 10:46 AM, Wiehe, Ulrich
      (NSN - DE/Munich) wrote:

    

    

      
      
      
      

        
Steve,

        
I agree, my comment
            and proposal do not hit the mark.

        
 

        
The intention was to
            say that known issues exist if there are multiple agents on
            multiple paths between client and server. The agents may not
            be able to ensure that there is no ambiguity in DOIC
            behaviour for the client. E.g. from the client’s point of
            view the answer to a first request (which was modified by
            agent A1) could indicate: DOIC is supported, currenty no
            overload, once in overload loss will be selected; and the
            answer to the next request (which was modified by agent A2)
            could indicate: DOIC is supported, some?? reduction is
            requested using rate. The client, however, may not be
            prepared for rate.

        
 

        
Maybe a warning note
            could be added to say that the agent may not always be able
            to ensure that there is no ambiguity.

        
 

        
Ulrich

        
 

        
 

        
 

        

          

            
From: DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext Steve Donovan

                Sent: Tuesday, December 09, 2014 2:45 PM

                To: dime@ietf.org

                Subject: [Dime] Ulrich's suggested change @12

          

        

        
 

        
Ulrich,

          

          For your suggested change #12:

        
Section 4.1.3, last paragraph:

        
Existing text:

        
   When making changes to the OC-Supported-Features AVP the Diameter

        
   Agent needs to ensure that there is no ambiguity in DOIC behavior for

        
   both upstream and downstream DOIC nodes.

        
 

        
Comment: while that is true, in addition problems similar to those 

        
identified in the note in section 3.3 may result from making changes.

        
 

        
Proposal: Add the note:

        
      Note: Known issues exist if multiple sources for overload reports

        
      which apply to the same Diameter entity exist.  Reacting nodes

        
      have no way of determining the source and, as such, will treat

        
      them as coming from a single source.  Variance in sequence numbers

        
      between the two sources can then cause incorrect overload

        
      abatement treatment to be applied for indeterminate periods of

        
      time.

        
I don't
          understand how these are related.  The change to the
          OC-Supported-Features AVP made by the agent apply only to the
          transaction.  In addition, this paragraph doesn't mention
          overload reports.

          

          Regards,

          

          Steve

          

          

      

    

    

  


--------------060405030408090602050005--


From nobody Wed Dec 10 04:49:14 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B9D1A1BBC for ; Wed, 10 Dec 2014 04:49:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.778
X-Spam-Level: 
X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1WwSJe8hbDF for ; Wed, 10 Dec 2014 04:49:04 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD341A1BDD for ; Wed, 10 Dec 2014 04:48:58 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50126 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XyghL-0007wE-U2; Wed, 10 Dec 2014 04:48:57 -0800
Message-ID: <54884137.4050209@usdonovans.com>
Date: Wed, 10 Dec 2014 06:48:55 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <5486FE71.70205@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235215@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815235215@DEMUMBX014.nsn-intra.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/81045IzGBR5Ee5-sxW7A4dRQE2A
Subject: Re: [Dime] Ulrich's suggested change #15
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 12:49:14 -0000

Ulrich,

Actually, the wording you suggested wasn't quite right.  It should be:

    When receiving an OC-OLR AVP with unknown values, the overload report
    SHOULD be silently discarded by reacting nodes and the event SHOULD
    be logged.

It's not just about report type values but unknown values for any of the 
AVPs in the OLR.

This seems like a good requirement to include in the specification to 
ensure common behavior in reacting nodes.  I don't feel strongly about 
this but I would like to hear other opinions.

Steve

On 12/9/14, 11:04 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Hi Steve,
>
> I think it was pointed out by Ben that we do not specify behaviour of a node for cases where it detects that another node is breaking the rule.
> The rule is:
>     A reporting node MUST NOT send overload reports of a type that has
>     not been advertised as supported by the reacting node.
> See section 4.2.3.
>
> Regards
> Ulrich
>
>    
>
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
> Sent: Tuesday, December 09, 2014 2:52 PM
> To: dime@ietf.org
> Subject: [Dime] Ulrich's suggested change #15
>
> Ulrich,
>
> For your suggested change #15:
> Section 4.2.1.3, 4th paragraph:
> Existing text:
>     When receiving an OC-OLR AVPs with unknown values, a reacting node
>     SHOULD be silently discarded by reacting nodes and the event SHOULD
>     be logged.
> Comment: text is confusing. Maybe the intention was to say:
>     When receiving an OC-OLR AVPs with an unsupported report type value, a reacting node
>     SHOULD silently discarded the OC-OLR AVP and the event SHOULD
>     be logged.
> But even that is not correct.
> Proposal: Remove the paragraph.
> The intent was that an OC-OLR that contains unknown values should be discarded.  I agree that the wording needs to be changes as you suggested.  I don't agree with removing the paragraph.  Can you elaborate on why you think it is not correct when changed as you suggested?
>
> Regards,
>
> Steve
>


From nobody Wed Dec 10 05:06:41 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3E91A8714 for ; Wed, 10 Dec 2014 05:06:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.779
X-Spam-Level: 
X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NlJ8llfzEY4 for ; Wed, 10 Dec 2014 05:06:36 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AED011A6F42 for ; Wed, 10 Dec 2014 05:06:36 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50162 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1XygyM-0001sW-Ls; Wed, 10 Dec 2014 05:06:34 -0800
Message-ID: <54884556.90108@usdonovans.com>
Date: Wed, 10 Dec 2014 07:06:30 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <548701E1.3060502@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235234@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815235234@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------050102010806030006050809"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/YO8wqX_TpdymRBPvtxpY5K6fzzc
Subject: Re: [Dime] Ulrich's suggested change #16
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 13:06:38 -0000

This is a multi-part message in MIME format.
--------------050102010806030006050809
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

I agree with your assumptions below.  For the third one, the only time 
it is possible, at least from a DOIC perspective, to send to another 
host is if it is a realm-routed request.  I might also change the "not 
overloaded" to "less overloaded".

I do think the statements can be improved to differentiate between 
behavior for host reports and realm reports.

How about the following:

    For OLRs of type host, if the request is a host-routed request then the reacting node SHOULD
    apply throttling abatement treatment to the request.

    For OLRs of type host, If the request is a realm-routed request then the reacting node
    SHOULD apply diversion abatement treatment to the request.

    For OLRs of type realm, the reacting node SHOULD
    apply throttling abatement treatment to the request, independent of the type (host-routed or
    realm-routed) of request.

Regards,

Steve

On 12/9/14, 11:29 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
> yes, then, maybe, the definition of Diversion is not correct?
> What are other people's views?
>
> My assumption was:
> If a host is overloaded, it does not help to direct traffic to that host via a different path.
> If a realm is overloaded, it does not help to direct traffic to that realm via a different path.
> If a host is overloaded, it helps to select an alternative (not overloaded) host (if possible) and direct traffic to that host.
> If a realm is overloaded, there never is an alternative (not overloaded) realm to which traffic could be directed.
>
> With the current definition of Diversion, Diversion is no appropriate means to address host overload and is no appropriate means to address realm overload. It may be ok for agent overload only.
>
> Regards
> Ulrich
>
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
> Sent: Tuesday, December 09, 2014 3:06 PM
> To: dime@ietf.org
> Subject: [Dime] Ulrich's suggested change #16
>
> Ulrich,
>
> For your suggested change #16:
> Section 4.2.2, 5th and 6th paragraph:
> Existing text:
>     If the request is a host-routed request then the reacting node SHOULD
>     apply throttling abatement treatment to the request.
>   
>     If the request is a realm-routed request then the reacting node
>     SHOULD apply diversion abatement treatment to the request.
>
> Comment: I don't think so. If the reacting node selects the server and
> then detects that the selected server is overloaded and then detects that
> the request does not survive (i.e. is subject to abatement), then the reacting
> node SHOULD apply diversion treatment (i.e. select an alternative server if possible).
> If the reacting node does not select the server (either a. because the server was
> already selected by a downstream node, or b. because the server will be selected
> by an upstream node) then there is no point in applying diversion and the reacting
> node SHOULD apply throttling of requests that do not survive.
>
> Proposal: replace the paragraphs with:
>     If the reacting node does not select the server then it SHOULD apply
>     throttling abatement to the request.
>
>     If the reacting node selects the server then it SHOULD apply diversion
>     abatement treatment (i.e. select an alternative server if possible) to
>     the request.
> Diversion is not selecting an alternative node to handle the request.  Diversion is selecting an alternative route to the selected node.
>
> Whether it is appropriate to select an alternative node for a request is an application decision that probably changes on a per command-code basis within the application.  Logic like this is outside the scope of the DOIC specification.
>
> The text is correct based on the definition of diversion.
>
> Regards,
>
> Steve
>


--------------050102010806030006050809
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

    

    I agree with your assumptions below.  For the third one, the only
    time it is possible, at least from a DOIC perspective, to send to
    another host is if it is a realm-routed request.  I might also
    change the "not overloaded" to "less overloaded".

    

    I do think the statements can be improved to differentiate between
    behavior for host reports and realm reports.

    

    How about the following:

    
    
   For OLRs of type host, if the request is a host-routed request then the reacting node SHOULD
   apply throttling abatement treatment to the request.

   For OLRs of type host, If the request is a realm-routed request then the reacting node
   SHOULD apply diversion abatement treatment to the request.


    
    
   For OLRs of type realm, the reacting node SHOULD
   apply throttling abatement treatment to the request, independent of the type (host-routed or 
   realm-routed) of request.



    Regards,

    

    Steve

    

    
On 12/9/14, 11:29 AM, Wiehe, Ulrich
      (NSN - DE/Munich) wrote:

    

    

      
Steve,
yes, then, maybe, the definition of Diversion is not correct?
What are other people's views?

My assumption was:
If a host is overloaded, it does not help to direct traffic to that host via a different path.
If a realm is overloaded, it does not help to direct traffic to that realm via a different path.
If a host is overloaded, it helps to select an alternative (not overloaded) host (if possible) and direct traffic to that host.
If a realm is overloaded, there never is an alternative (not overloaded) realm to which traffic could be directed.

With the current definition of Diversion, Diversion is no appropriate means to address host overload and is no appropriate means to address realm overload. It may be ok for agent overload only.

Regards
Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 09, 2014 3:06 PM
To: dime@ietf.org
Subject: [Dime] Ulrich's suggested change #16

Ulrich,

For your suggested change #16:
Section 4.2.2, 5th and 6th paragraph:
Existing text:
   If the request is a host-routed request then the reacting node SHOULD
   apply throttling abatement treatment to the request.
 
   If the request is a realm-routed request then the reacting node
   SHOULD apply diversion abatement treatment to the request.

Comment: I don't think so. If the reacting node selects the server and 
then detects that the selected server is overloaded and then detects that 
the request does not survive (i.e. is subject to abatement), then the reacting 
node SHOULD apply diversion treatment (i.e. select an alternative server if possible). 
If the reacting node does not select the server (either a. because the server was 
already selected by a downstream node, or b. because the server will be selected 
by an upstream node) then there is no point in applying diversion and the reacting 
node SHOULD apply throttling of requests that do not survive.

Proposal: replace the paragraphs with:
   If the reacting node does not select the server then it SHOULD apply
   throttling abatement to the request.

   If the reacting node selects the server then it SHOULD apply diversion
   abatement treatment (i.e. select an alternative server if possible) to
   the request.
Diversion is not selecting an alternative node to handle the request.  Diversion is selecting an alternative route to the selected node.  

Whether it is appropriate to select an alternative node for a request is an application decision that probably changes on a per command-code basis within the application.  Logic like this is outside the scope of the DOIC specification.

The text is correct based on the definition of diversion.

Regards,

Steve



    

    

  


--------------050102010806030006050809--


From nobody Wed Dec 10 07:09:40 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F2F1A6FC0 for ; Wed, 10 Dec 2014 07:09:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWB0hTpMbktC for ; Wed, 10 Dec 2014 07:09:23 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42F01A0103 for ; Wed, 10 Dec 2014 07:09:20 -0800 (PST)
X-AuditID: c1b4fb3a-f79116d000000fec-86-5488621f47a6
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F6.4F.04076.F1268845; Wed, 10 Dec 2014 16:09:19 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.41]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 16:09:18 +0100
From: Maria Cruz Bartolome 
To: Steve Donovan , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "lionel.morand@orange.com" , Ben Campbell 
Thread-Topic: [Dime] Updates to DOIC -05
Thread-Index: AQHP96zTVLWd5veGrkqAoFDKpocx+ZxXdZWAgAKB9QCAABTjgIABToGAgABXjYCAAImqAIAAtOqAgAHz+gCAAFg3AIAFNTcAgAARHgCABzpwAIAFs+cAgABIhYCACwbhAIABEZ9ggAATtICAAFSrgIAKq7Mg
Date: Wed, 10 Dec 2014 15:09:18 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920987F790@ESESSMB101.ericsson.se>
References: <545792B6.8030502@usdonovans.com> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, > <087A34937E64E74E848732CFF8354B9209863A54@ESESSMB101.ericsson.se> <24987_1416213505_5469B401_24987_4151_1_judb1lo2cnj5m4v6mdt5aec1.1416213483721@email.android.com>  <54748CEA.3020705@usdonovans.com> <19072_1416939968_5474C9C0_19072_1519_1_6B7134B31289DC4FAF731D844122B36E941639@PEXCVZYM13.corporate.adroot.infra.ftgroup> <547E09C0.5080305@usdonovans.com>   <547F46D5.7060800@usdonovans.com>
In-Reply-To: <547F46D5.7060800@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920987F790ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM+Jvja58UkeIwYrVAhbzO0+zW8ztXcFm sen8OhaL29szLTY08TiwerQ+28vqsWTJTyaPWTufsHi0PDvJ5rHqbR9rAGsUl01Kak5mWWqR vl0CV0bLzAesBW3rmCpuTV3I3sA4p4Wpi5GTQ0LAROJ29zRGCFtM4sK99WxdjFwcQgJHGCVu fjzNCuEsZpRo+jYPrIpNwE7i0ukXTCAJEYHbjBL/Dr5lBkkwCyhLzN7xgB3EFhZQl1i+8xcr iC0ioCHRd2Q1M0TDKkaJay2tLCAJFgFViVXnv4M18wr4ShzffBUsLiTwm11i8iY+EJtTQE/i cvdVNhCbEei+76fWMEEsE5e49WQ+1A8CEkv2nGeGsEUlXj7+xwphK0ksuv0Zqj5fYkXrH6hd ghInZz5hmcAoOgvJqFlIymYhKYOI60ncmDqFDcLWlli28DUzhK0rMePfIRZk8QWM7KsYRYtT i4tz042M9FKLMpOLi/Pz9PJSSzYxAiP24JbfVjsYDz53PMQowMGoxMNb8L49RIg1say4MvcQ ozQHi5I478Jz84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MIq0LrHYfzrBbOHmNwVZFeJf F0hWXKu6rmL1tWbn4zNTf5y5HZq0jEl6xz+1FHbrf1VZIimsLzds2pN/vE4mb/mcc3MeP+Fd JnHtlp61ZAj37NusnvnvlbtSCt1dGgV2qFZtP+viK/nulb+ahJvEXb/by/ayH5110VH87P6Z Kg1bFCfM9slWCVFiKc5INNRiLipOBABKnWiDuQIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/SuCvVETmhi52EG9FGdm4oRtdBk0
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Updates to DOIC -05
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 15:09:31 -0000

--_000_087A34937E64E74E848732CFF8354B920987F790ESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear all,

I have the following proposal, for first paragraph
Now:

Therefore, before

   applying local message throttling, a reporting node needs to check if
   these messages match existing OCS entries,

Proposal

Therefore, before

   applying local message throttling, a reporting node MAY check if
   these messages match existing OCS entries,

I think the reporting node may or not check whether the received messages m=
atch a "delegated" active OCS. This is a processing consuming task that cou=
ld be avoided if the reporting node uses different criteria to choose messa=
ges to drop/reject. This is up to  implementation.

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: mi=E9rcoles, 03 de diciembre de 2014 18:22
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); lionel.morand@orange.com; Ben Cam=
pbell
Cc: dime@ietf.org
Subject: Re: [Dime] Updates to DOIC -05

I have attempted to address both Lionel's and Jean-Jacques' suggestions wit=
h the following text:

   When a reporting node sends an OLR, it effectively delegates any

   necessary throttling to downstream nodes.  If the reporting node also

   locally throttles the same set of messages, the overall number of

   throttled requests may be higher than intended.  Therefore, before

   applying local message throttling, a reporting node needs to check if

   these messages match existing OCS entries, indicating that these

   messages have survived throttling applied by downstream nodes that

   have received the related OLR.



   However, even if the set of messages match existing OCS entries, the

   reporting node can still apply other abatement methods such as

   diversion.  The reporting node might also need to throttle requests

   for reasons other than overload.  For example, an agent or server

   might have a configured rate limit for each client, and throttle

   requests that exceed that limit, even if such requests had already

   been candidates for throttling by downstream nodes.  The reporting

   node also has the option to send new OLRs requesting greater

   reductions in traffic, reducing the need for local throttling.

Steve
On 12/3/14, 6:19 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
Dear all

To continue on my remark , I would complement the Steve's text with " can u=
pdate the reduction of traffic it requires from the reacting nodes(s) by se=
nding new overload reports" as hereafter:



   Therefore, if a

   reporting node needs to apply local throttling on a set of messages

   that match existing OCS entries, it needs to consider

   the impact of throttling by downstream nodes and can update the reductio=
n of traffic it requires from the reacting nodes(s) by sending new overload=
 reports.


Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Envoy=E9 : mercredi 3 d=E9cembre 2014 11:29
=C0 : Steve Donovan; lionel.morand@orange.com; Ben Campbell
Cc : dime@ietf.org
Objet : Re: [Dime] Updates to DOIC -05

Dear all

I am not against the new proposed texts from Steve or Ben to clarify this t=
opic.

My point is that, when  the reporting node has sent an OLR requiring  a tra=
ffic reduction , there is first a reaction time before receiving reduced tr=
affic, and second even if the traffic has been reduced, it can still exceed=
 the capacity of the reporting node  that has no other choice than to throt=
tle the received reduced traffic (if no diversion). This can happen when th=
e traffic at the source (reacting node) before throttling is increasing qui=
ckly, so the traffic reduced  according to the received OLR may  remain too=
 high .  Then, if the reporting node has nevertheless to do some throttle, =
it will certainly react by new OLRs requiring a higher traffic reduction fr=
om the reacting nodes. This is a dynamic process, where the reporting node =
adjust the  traffic  reduction it requires according to what it receives .

As Ben  I also think this is a guidance , and I think it is good to bring s=
ome guidance.

Best regards

JJacques

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mardi 2 d=E9cembre 2014 19:50
=C0 : lionel.morand@orange.com; Ben Campbe=
ll
Cc : dime@ietf.org
Objet : Re: [Dime] Updates to DOIC -05

Lionel,

The two paragraphs together now say the following:

   When a reporting node sends an OLR, it effectively delegates any

   necessary throttling to downstream nodes.  If the reporting node also

   locally throttles the same set of messages, the overall number of

   throttled request may be higher than intended.  Therefore, if a

   reporting node needs to apply local throttling on a set of messages

   that match or overlap with existing OCS entries, it needs to consider

   the impact of throttling by downstream nodes.



   However, when the reporting node sends an OLR downstream, it might

   still need to apply other abatement methods such as diversion.  The

   reporting node might also need to throttle requests for reasons other

   than overload.  For example, an agent or server might have a

   configured rate limit for each client, and throttle requests that

   exceed that limit, even if such requests had already been candidates

   for throttling by downstream nodes.
Do you see the need for further clarification?

Steve
On 11/25/14, 12:26 PM, lionel.morand@orange.com wrote:

I'm OK with the idea of the text proposed by Ben.

I would just make clear that throttling is applicable to the fact of sendin=
g/forwarding requests (cf. definition). A reporting node may apply local th=
rottling if it is an agent. But if it is a server, it can either drop the e=
xceeded number of requests (no response sent to the downstream) or send a s=
pecific DIAMETER-TOO-BUSY response. I think that this clarification is some=
how missing in the document.



Regards,



Lionel



-----Message d'origine-----

De : Steve Donovan [mailto:srdonovan@usdonovans.com]

Envoy=E9 : mardi 25 novembre 2014 15:07

=C0 : Ben Campbell; MORAND Lionel IMT/OLN

Cc : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; =
Maria Cruz Bartolome

Objet : Re: [Dime] Updates to DOIC -05



I'm ok with Ben's wording and will make the change unless I hear objections=
 on the list.



Steve



On 11/21/14, 5:01 PM, Ben Campbell wrote:

On reflection, I think there might be a subtlety here. The resulting offere=
d-load may still exceed the reporting node's current capacity. This can be =
true even if it's sent an OLR (and thus has related OCS). As mentioned in t=
he surrounding node needs to still be able to protect itself, possibly by t=
hrottling. Therefore, I propose the sentence take the form of non-normative=
 guidance. For example:



"When a reporting node sends an OLR, it effectively delegates any necessary=
 throttling to downstream nodes.  If the reporting node also locally thrott=
les the same set of messages, the overall number of throttled request may b=
e higher than intended. Therefore, if a reporting node needs to apply local=
 throttling on a set of messages that match or overlap with existing OCS en=
tries, it needs to consider the impact of throttling by downstream nodes."





On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com wrote:



I can live with the text proposed by Ulrich. But what is wrong with:



" Therefore, the reporting node SHOULD NOT apply throttling to the set of m=
essages to which an active OCS applies." ?



Envoy=E9 depuis mon Sony Xperia SP d'Orange



---- Maria Cruz Bartolome a =E9crit ----





Section 4.2.3, 13th paragraph, 2nd sentence:

Existing text: Therefore, the reporting node SHOULD NOT apply throttling to=
 the set of messages to which the OLR applies.

Proposed text: Therefore, the reporting node SHOULD NOT apply throttling to=
 the set of messages to which the sent OLR applies.



[LM] I would say that the reporting node will not remember the previously s=
ent OLR, but will take care that there is an active OCS.

SRD> I'm ok with Ulrich's change.



[LM] and this is incorrect but not fundamental. The reporting node does not=
 have to "remember" a previously sent OLR. What it will do is to refer to e=
xisting OCS to know that throttling should not be applied. An OCS is a cons=
equence of an sent OLR but it is not an OLR itself. But not fundamental her=
e.



[MCruz] I am ok with Ulrich's change. It does not mean that the reporting n=
ode needs to "remember" a previously sent OLR, though. The change only prop=
oses to "identify" which OLR we refer to.



Best regards

/MCruz





_____________________________________________________________________

____________________________________________________



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 le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n, 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 dis=
tributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and dele=
te 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

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime







___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.







--_000_087A34937E64E74E848732CFF8354B920987F790ESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Dear all,


 <=
/p>

I have the=
 following proposal, for first paragraph


Now:<=
/o:p>


Therefore, before


   applying local message throttling, a=
 reporting node needs to check if


   these messages mat=
ch existing OCS entries,


 =
;


Proposal


Therefore, before


   applying local message throttling, a=
 reporting node MAY check if


   these messages mat=
ch existing OCS entries,


 =
;


I think th=
e reporting node may or not check whether the received messages match a =
220;delegated” active OCS. This is a processing consuming task that
 could be avoided if the reporting node uses different criteria to choose m=
essages to drop/reject. This is up to  implementation.


 =
;


Best regar=
ds


/MCruz


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of Steve Donovan

Sent: mi=E9rcoles, 03 de diciembre de 2014 18:22

To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); lionel.morand@orange.com; =
Ben Campbell

Cc: dime@ietf.org

Subject: Re: [Dime] Updates to DOIC -05






 


I have attempted to a=
ddress both Lionel's and Jean-Jacques' suggestions with the following text:=



   When a reporting node sends an OLR, it effectively delega=
tes any


   necessary throttling to downstream nodes.  If the re=
porting node also


   locally throttles the same set of messages, the overall n=
umber of


   throttled requests may be higher than intended.  The=
refore, before


   applying local message throttling, a reporting node needs=
 to check if


   these messages match existing OCS entries, indicating tha=
t these


   messages have survived throttling applied by downstream n=
odes that


   have received the related OLR.


 


   However, even if the set of messages match existing OCS e=
ntries, the


   reporting node can still apply other abatement methods su=
ch as


   diversion.  The reporting node might also need to th=
rottle requests


   for reasons other than overload.  For example, an ag=
ent or server


   might have a configured rate limit for each client, and t=
hrottle


   requests that exceed that limit, even if such requests ha=
d already


   been candidates for throttling by downstream nodes. =
 The reporting


   node also has the option to send new OLRs requesting grea=
ter


   reductions in traffic, reducing the need for local thrott=
ling.




Steve




On 12/3/14, 6:19 AM, TROTTIN, JEAN-JACQUES (JEAN-JAC=
QUES) wrote:






Dear all


 <=
/p>

To continue on my remark =
, I would complement the Steve’s text with “
can update the reduction of traffic it requires from the=
 reacting nodes(s) by sending new overload reports”
as hereafter:    


 


   Therefore, if a


   reporting node needs to apply local throttling on a set o=
f messages


   that match existing OCS entries, it needs to consider


   the impact of throttling by downstream nodes and can upda=
te the reduction of traffic it requires from the reacting nodes(s) by sendi=
ng new overload reports. 


 


Best regards<=
/o:p>


 <=
/p>

JJacques



 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Envoy=E9 : mercredi 3 d=E9cembre 2014 11:29

=C0 : Steve Donovan; lionel.morand@orange.com; Ben Campbell

Cc : dime@ietf.org

Objet : Re: [Dime] Updates to DOIC -05






 


Dear all


 <=
/p>

I am not against the new =
proposed texts from Steve or Ben to clarify this topic.

 <=
/p>

My point is that, when &n=
bsp;the reporting node has sent an OLR requiring  a traffic reduction =
, there is first a reaction time before receiving reduced traffic,
 and second even if the traffic has been reduced, it can still exceed the c=
apacity of the reporting node  that has no other choice than to thrott=
le the received reduced traffic (if no diversion). This can happen when the=
 traffic at the source (reacting node)
 before throttling is increasing quickly, so the traffic reduced  acco=
rding to the received OLR may  remain too high .  Then, if the re=
porting node has nevertheless to do some throttle, it will certainly react =
by new OLRs requiring a higher traffic reduction
 from the reacting nodes. This is a dynamic process, where the reporting no=
de adjust the  traffic  reduction it requires according to what i=
t receives .


 <=
/p>

As Ben  I also think=
 this is a guidance , and I think it is good to bring some guidance.



 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques



 <=
/p>





De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mardi 2 d=E9cembre 2014 19:50

=C0 : lionel.morand=
@orange.com; Ben Campbell

Cc : dime@ietf.org

Objet : Re: [Dime] Updates to DOIC -05






 


Lionel,



The two paragraphs together now say the following:


   When a reporting node sends an OLR, it effectively delega=
tes any


   necessary throttling to downstream nodes.  If the re=
porting node also


   locally throttles the same set of messages, the overall n=
umber of


   throttled request may be higher than intended.  Ther=
efore, if a


   reporting node needs to apply local throttling on a set o=
f messages


   that match or overlap with existing OCS entries, it needs=
 to consider


   the impact of throttling by downstream nodes.<=
/pre>

 


   However, when the reporting node sends an OLR downstream,=
 it might


   still need to apply other abatement methods such as diver=
sion.  The


   reporting node might also need to throttle requests for r=
easons other


   than overload.  For example, an agent or server migh=
t have a


   configured rate limit for each client, and throttle reque=
sts that


   exceed that limit, even if such requests had already been=
 candidates


   for throttling by downstream nodes.


Do you see the need f=
or further clarification?



Steve




On 11/25/14, 12:26 PM, 
lionel.morand@orange.com wrote:






I'm OK with the idea of the text proposed by Ben.


I would just make clear that throttling is applicable to the fact of s=
ending/forwarding requests (cf. definition). A reporting node may apply loc=
al throttling if it is an agent. But if it is a server, it can either drop =
the exceeded number of requests (no response sent to the downstream) or sen=
d a specific DIAMETER-TOO-BUSY response. I think that this clarification is=
 somehow missing in the document.


 


Regards,


 


Lionel


 


-----Message d'origine-----


De : Steve Donovan [m=
ailto:srdonovan@usdonovans.com] 


Envoy=E9 : mardi 25 novembre 2014 15:07


=C0 : Ben Campbell; MORAND Lionel IMT/OLN


Cc : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; Maria Cruz Bartolome


Objet : Re: [Dime] Updates to DOIC -05


 


I'm ok with Ben's wording and will make the change unless I hear objec=
tions on the list.


 


Steve


 


On 11/21/14, 5:01 PM, Ben Campbell wrote:




On reflection, I think there might be a subtlety here. The resulting o=
ffered-load may still exceed the reporting node's current capacity. This ca=
n be true even if it's sent an OLR (and thus has related OCS). As mentioned=
 in the surrounding node needs to still be able to protect itself, possibly=
 by throttling. Therefore, I propose the sentence take the form of non-norm=
ative guidance. For example:


 


"When a reporting node sends an OLR, it effectively delegates any=
 necessary throttling to downstream nodes.  If the reporting node also=
 locally throttles the same set of messages, the overall number of throttle=
d request may be higher than intended. Therefore, if a reporting node needs=
 to apply local throttling on a set of messages that match or overlap with =
existing OCS entries, it needs to consider the impact of throttling by down=
stream nodes."


 


  




On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com wrote:


 


I can live with the text proposed by Ulrich. But what is wrong with:


 


" Therefore, the reporting node SHOULD NOT apply throttling to th=
e set of messages to which an active OCS applies." ?


 


Envoy=E9 depuis mon Sony Xperia SP d'Orange


 


---- Maria Cruz Bartolome a =E9crit ----


 


 




Section 4.2.3, 13th paragraph, 2nd sentence:


Existing text: Therefore, the reporting node SHOULD NOT apply throttli=
ng to the set of messages to which the OLR applies.


Proposed text: Therefore, the reporting node SHOULD NOT apply throttli=
ng to the set of messages to which the sent OLR applies.


 


[LM] I would say that the reporting node will not remember the previou=
sly sent OLR, but will take care that there is an active OCS.



SRD> I'm ok with Ulrich's change.


 


[LM] and this is incorrect but not fundamental. The reporting node doe=
s not have to "remember" a previously sent OLR. What it will do i=
s to refer to existing OCS to know that throttling should not be applied. A=
n OCS is a consequence of an sent OLR but it is not an OLR itself. But not =
fundamental here.


 


[MCruz] I am ok with Ulrich's change. It does not mean that the report=
ing node needs to "remember" a previously sent OLR, though. The c=
hange only proposes to "identify" which OLR we refer to.


 


Best regards


/MCruz


 


 


_____________________________________________________________________<=
o:p>


____________________________________________________


 


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 q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration, Orange decline toute responsabilite si ce message a ete altere, def=
orme ou falsifie. Merci.


 


This message and its attachments may contain confidential or 


privileged information that may be protected by law; they should not b=
e 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


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




 


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.


 


 




 




 






--_000_087A34937E64E74E848732CFF8354B920987F790ESESSMB101erics_--


From nobody Wed Dec 10 07:09:42 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A4D1A0047 for ; Wed, 10 Dec 2014 07:09:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RfPXdcR0ttp for ; Wed, 10 Dec 2014 07:09:31 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BDAA1A0173 for ; Wed, 10 Dec 2014 07:09:22 -0800 (PST)
X-AuditID: c1b4fb3a-f79116d000000fec-96-548862215784
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C8.4F.04076.12268845; Wed, 10 Dec 2014 16:09:21 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.41]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 16:09:20 +0100
From: Maria Cruz Bartolome 
To: "lionel.morand@orange.com" , Jouni , "dime@ietf.org list" 
Thread-Topic: Call for WG adoption: draft-donovan-dime-doc-rate-control
Thread-Index: AQHQDuelOYAgmWNJ6UiPoL1QuUCDoZyIvBgw
Date: Wed, 10 Dec 2014 15:09:19 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920987F796@ESESSMB101.ericsson.se>
References:  <17900_1417604115_547EEC13_17900_1759_1_6B7134B31289DC4FAF731D844122B36E99A6FD@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <17900_1417604115_547EEC13_17900_1759_1_6B7134B31289DC4FAF731D844122B36E99A6FD@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvja5iUkeIwZv3AhZze1ewWexf18Bk cXt7pgOzx85Zd9k9liz5yeTR8uwkWwBzFJdNSmpOZllqkb5dAlfG3B1vmAsuCFas+hbdwPiA r4uRk0NCwESiofUPE4QtJnHh3nq2LkYuDiGBI4wSc75+YIZwFjNK/Pm/hBmkik3ATuLS6Rdg HSICjYwSL1rUQGxhATeJX5cvsUHE3SWuL57HCGEbSXzsWQJWzyKgKvH53wqwGl4BX4kLa+ey QyzYwShxfW0HC4jDKdDGKNH5ZCdYByPQTd9PrQGzmQXEJW49mQ91q4DEkj3nmSFsUYmXj/+x QthKEotuf4aq15O4MXUKG4StLbFs4WtmiM2CEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG 0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwOg5uOW31Q7Gg88dDzEKcDAq8fAWvG8PEWJNLCuu zD3EKM3BoiTOu/DcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjCL6Het+VS7PKCl+c+eI XYD6rb3HQ646bfNVCuR+mqA+OYNTeFrrZSPujc+//nhcznDh/OpzVnP+V762O3kr2MFc42sk d4eJsp1P+NVpJ6O9leaVOQnfiHd85s6aWmQVc5SjeMv+wnsaK9Zqv3sap6W1YldV4g9lKeUr /wsN7t+yPPRUbeK/YCWW4oxEQy3mouJEAELjLxZ/AgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Hk9QkKpKgrjUM5JvSgezGsj7Qpo
Subject: Re: [Dime] Call for WG adoption: draft-donovan-dime-doc-rate-control
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 15:09:33 -0000

Dear all,

I support adoption.
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange=
.com
Sent: mi=E9rcoles, 03 de diciembre de 2014 11:55
To: Jouni; dime@ietf.org list
Subject: Re: [Dime] Call for WG adoption: draft-donovan-dime-doc-rate-contr=
ol

As individual, I support.

Lionel

-----Message d'origine-----
De=A0: Jouni [mailto:jouni.nospam@gmail.com] Envoy=E9=A0: mercredi 3 d=E9ce=
mbre 2014 11:12 =C0=A0: dime@ietf.org list Cc=A0: MORAND Lionel IMT/OLN; Jo=
uni Objet=A0: Call for WG adoption: draft-donovan-dime-doc-rate-control

Folks,

As we discussed and agreed during the Honolulu meeting we ask for the WG ad=
option for draft-donovan-dime-doc-rate-control unless counter proposals sho=
w up. The "wait period" for counter proposals has been more than enough.

This mail starts a two week adoption call for draft-donovan-dime-doc-rate-c=
ontrol as a WG Item.

Express your support or disagreements in the mailing list. The call ends 17=
th Dec EOB (CET+1).

- Jouni & Lionel


___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te 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
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Dec 10 07:09:43 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132E21A0047 for ; Wed, 10 Dec 2014 07:09:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level: 
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJrRHjswBBpG for ; Wed, 10 Dec 2014 07:09:21 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825491A0065 for ; Wed, 10 Dec 2014 07:09:19 -0800 (PST)
X-AuditID: c1b4fb2d-f79fc6d000001087-b5-5488621dae02
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 51.DF.04231.D1268845; Wed, 10 Dec 2014 16:09:17 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.41]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 16:09:16 +0100
From: Maria Cruz Bartolome 
To: Ben Campbell , "dime@ietf.org list" 
Thread-Topic: [Dime] Updated DOIC Requirements Analysis
Thread-Index: AQHQCFYt6tScBxBsq0iC3L6bres0LpyIv54A
Date: Wed, 10 Dec 2014 15:09:16 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920987F783@ESESSMB101.ericsson.se>
References: <46C8B155-A8B0-41F6-A8A5-6F21D61ADE9E@nostrum.com>
In-Reply-To: <46C8B155-A8B0-41F6-A8A5-6F21D61ADE9E@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920987F783ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM+Jvja5sUkeIwcmbqhbzO0+zW8ztXcHm wOSxZMlPJo9ZO5+wBDBFcdmkpOZklqUW6dslcGVcv9jDWHChlbXixIWDzA2MM+eydDFyckgI mEj8X/uDGcIWk7hwbz1bFyMXh5DAEUaJ2X3fWSGcxYwSJ1b9YwepYhOwk7h0+gUTiC0i4CHx YnMb2CRhATOJrlk72CDi5hJTF2xmhrCNJPY3n2MFsVkEVCVWPdwHFucV8JU4/XIt2BwhoJnv tnwG6+UUsJd4tfMD2C5GoIu+n1oDVsMsIC5x68l8JohLBSSW7DkPdbWoxMvH/1ghbCWJRbc/ Q9XnS8yeP4kNYpegxMmZT1gmMIrMQjJqFpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZ fAEj+ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwOg6uOW37g7G1a8dDzEKcDAq8fAWvG8P EWJNLCuuzD3EKM3BoiTOu+jcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjOZW7+ctM7m7 x8HCwjTqxOU7AjfslXPOruZbMOmLxyNf28vZZetnTl18TcO64OTv43NvTkm/9q/F6Or7DX98 HB68uyX11ft5nf2nV/srgg89O2DjukqZY2P9CQYG6+YlV0sPz/pevSBha3/BMsXdU4R0Hecz zff3Xca3Sb3wxMWflcw779841u6ixFKckWioxVxUnAgAQkyJEI8CAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/51qrOR5GnHH8ALwm5pEpT03I9vU
Subject: Re: [Dime] Updated DOIC Requirements Analysis
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 15:09:35 -0000

--_000_087A34937E64E74E848732CFF8354B920987F783ESESSMB101erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,

See some comments below
Thanks
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: martes, 25 de noviembre de 2014 3:19
To: dime@ietf.org list
Subject: [Dime] Updated DOIC Requirements Analysis

Here's the text from the updated requirements analysis. I updated the summa=
ry 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 reser=
ved 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 (gener=
ally, 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 u=
nderstand 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.


--_000_087A34937E64E74E848732CFF8354B920987F783ESESSMB101erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hello,<=
/p>

 <=
/p>

See some comments below


Thanks<=
/p>

/MCruz<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Ben Campbell

Sent: martes, 25 de noviembre de 2014 3:19

To: dime@ietf.org list

Subject: [Dime] Updated DOIC Requirements Analysis=







 


Here's the text from the updated requirements analys=
is. I updated the summary to be more general, and updated the detail based =
on mail discussion. The detail section is marked for deletion before public=
ation 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 DO=
IC solutions


   conformance to the requirements defined in [RFC7068].


 


C.1.  Deferred Requirements


 


   The DIME working group chose to defer certain requirement=
s in order


   to meet an an external deadline.  The 3GPP "Cor=
e 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 d=
eferred work


   includes the following:


 


   o  Agent Overload - The ability for an agent to repo=
rt an overload


      condition of the agent itself.


 


   o  Load Information - The ability for a node to repo=
rt 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 su=
pporting


   nodes to automatically determine whether OC-Supported-Fea=
tures 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 im=
possible to


   detect the presence of non-supporting nodes between suppo=
rting nodes,


   except by configuration.  The working group determin=
ed that such a


   configuration requirement is acceptable.


 


   This limits full compliance with certain requirements rel=
ated to the


   limitation of new configuration, deployment in environmen=
ts with


   mixed support, operating across non-supporting agents, an=
d


   authorization.


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


Morever, since detailed desc=
riptions will be deleted.


 


C.3.  Implicit Application Indication


 


   The working group elected to determine the application fo=
r an


   overload report from that of the enclosing message. =
 This prevents


   sending an OLR for an application when there are no trans=
actions for


   that application.


 


   As a consequence, DOIC does not comply with the requireme=
nt to be


   able to report overload information across quiescent conn=
ections.


   DOIC does not fully comply with requirements to operate o=
n up-to-date


   information, since if an OLR causes all transactions to s=
top 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 eve=
ry answer


   message, as part of the requirement to avoid additional w=
ork for


   overloaded nodes.  DOIC recommends exactly that beha=
vior during


   active overload conditions.  The working group deter=
mined that doing


   otherwise would reduce reliability and increase statefuln=
ess.  (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 th=
e


   requirement to avoid introducing new vulnerabilities.&nbs=
p; However, this


   requirement may warrant an early security expert review.<=
o:p>


 


C.6.  Detailed Requirements


 


   [RFC Editor: Please remove this section and subsections p=
rior to


   publication as an RFC.]


 


C.6.1.  General


 


   REQ 1:  The solution MUST provide a communication me=
thod for Diameter


           nodes to =
exchange load and overload information.


 


           *Partiall=
y Compliant*. The mechanism uses new AVPs


           piggyback=
ed on existing Diameter messages to exchange


           overload =
information.  It does not currently support "load"


           informati=
on or the ability to report overload of an agent.


           These hav=
e been left for future extensions.


 


 


 


   REQ 2:  The solution MUST allow Diameter nodes to su=
pport overload


           control r=
egardless of which Diameter applications they


           support.&=
nbsp; 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 ove=
rload conditions is best described by REQ 3.


 


           *Partiall=
y Compliant*. The DOIC AVPs can be used in any


           applicati=
on that allows the extension of AVPs.  However,


           "loa=
d" information is not currently supported.


 


 


 


   REQ 3:  The solution MUST limit the impact of overlo=
ad on the overall


           useful th=
roughput 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.


 


           *Complian=
t*. DOIC provides information that nodes can use to


           reduce th=
e impact of overload.


 


 


 


   REQ 4:  Diameter allows requests to be sent from eit=
her side of a


           connectio=
n, and either side of a connection may have need to


           provide i=
ts overload status.  The solution MUST allow each


           side of a=
 connection to independently inform the other of its


           overload =
status.


 


           *Complian=
t*. DOIC AVPs can be included regardless of


           transacti=
on "direction"


 


 


 


   REQ 5:  Diameter allows nodes to determine their pee=
rs via dynamic


           discovery=
 or manual configuration.  The solution MUST work


           consisten=
tly without regard to how peers are determined.


 


           *Complian=
t*. DOIC contains no assumptions about how peers are


           discovere=
d.


 


 


 


   REQ 6:  The solution designers SHOULD seek to minimi=
ze the amount of


           new confi=
guration required in order to work.  For example, it


           is better=
 to allow peers to advertise or negotiate support


           for the s=
olution, rather than to require that this knowledge


           to be con=
figured at each node.


 


           *Partiall=
y Compliant*. Most DOIC parameters are advertised


           using the=
 DOIC capability announcement mechanism.  However,


           there are=
 some situations where configuration is required.


           For examp=
le, a DOIC node detect the fact that a peer may not


           support D=
OIC when nodes on the other side of the non-


           supportin=
g node do support DOIC without configuration.


 


[MCruz] Could you clarify la=
st example? “withoug configuration”? I do not understand what y=
ou meant.


 


C.6.2.  Performance


 


   REQ 7:  The solution and any associated default algo=
rithm(s) MUST


           ensure th=
at the system remains stable.  At some point after


           an overlo=
ad condition has ended, the solution MUST enable


           capacity =
to stabilize and become equal to what it would be in


           the absen=
ce of an overload condition.  Note that this also


           requires =
that the solution MUST allow nodes to shed load


           without i=
ntroducing non-converging oscillations during or


           after an =
overload condition.


 


           *Complian=
t*. The specification offers guidance that


           implement=
ations should apply hysteresis when recovering from


           overload,=
 and avoid sudden ramp ups in offered load when


           recoverin=
g.


 


 


 


   REQ 8:  Supporting nodes MUST be able to distinguish=
 current overload


           informati=
on from stale information.


 


           *Partiall=
y Compliant*. DOIC overload reports are "soft


           state&quo=
t;, that is they expire after an indicated period.  DOIC

           nodes may=
 also send reports that end existing overload


           condition=
s.  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 w=
atchdog messages, if an overload condition results


           in zero o=
ffered load, the reporting node cannot update the


           condition=
 until the expiration of the original OLR.


 


 


 


   REQ 9:  The solution MUST function across fully load=
ed as well as


           quiescent=
 transport connections.  This is partially derived


           from the =
requirement for stability in REQ 7.


 


           *Not Comp=
liant*. 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 appl=
y.


 


 


 


   REQ 10: Consumers of overload information MUST be able to=
 determine


           when the =
overload condition improves or ends.


 


           *Partiall=
y Compliant*. (See response to previous two


           requireme=
nts.)


 


 


 


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


           sizes.


 


           *Complian=
t*. DOIC makes no assumptions about the size of the


           network.&=
nbsp; DOIC can operate purely between clients and


           servers, =
or across agents.


 


 


 


   REQ 12: When a single network node fails, goes into overl=
oad, or


           suffers f=
rom reduced processing capacity, the solution MUST


           make it p=
ossible to limit the impact of the affected node on


           other nod=
es in the network.  This helps to prevent a small-


           scale fai=
lure from becoming a widespread outage.


 


           *Partiall=
y Compliant*. DOIC allows overload reports for an


           entire re=
alm, where abated traffic will not be redirected


           towards a=
nother server.  But in situations where nodes choose


           to divert=
 traffic to other nodes, DOIC offers no way of


           knowing w=
hether 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 o=
f proprietary dynamic load-balancing mechanisms.


 


 


 


   REQ 13: The solution MUST NOT introduce substantial addit=
ional work


           for a nod=
e in an overloaded state.  For example, a


           requireme=
nt for an overloaded node to send overload


           informati=
on every time it received a new request would


           introduce=
 substantial work.


 


           *Not Comp=
liant*. DOIC does in fact encourage an overloaded


           node to s=
end an OLR in every response.  The working group


           that othe=
r mechanisms to ensure that every relevant node


           receives =
an OLR would create even more work.  [Note: This


           needs dis=
cussion.]


 


 


 


   REQ 14: Some scenarios that result in overload involve a =
rapid


           increase =
of traffic with little time between normal levels


           and level=
s that induce overload.  The solution SHOULD provide


           for rapid=
 feedback when traffic levels increase.


 


           *Complian=
t*. The piggyback mechanism allows OLRs to be sent


           at the sa=
me rate as application traffic.


 


 


 


   REQ 15: The solution MUST NOT interfere with the congesti=
on control


           mechanism=
s of underlying transport protocols.  For example, a


           solution =
that opened additional TCP connections when the


           network i=
s congested would reduce the effectiveness of the


           underlyin=
g congestion control mechanisms.


 


           *Complian=
t*. DOIC does not require or recommend changes in


           the handl=
ing of transport protocols or connections.


 


 


 


C.6.3.  Heterogeneous Support for Solution


 


   REQ 16: The solution is likely to be deployed incremental=
ly.  The


           solution =
MUST support a mixed environment where some, but not


           all, node=
s implement it.


 


           *Partiall=
y Compliant*. DOIC works with most mixed-deployment


           scenarios=
.  However, it cannot work across a non-supporting


           proxy tha=
t modifies Origin-Host AVPs in answer messages.


           DOIC will=
 have limited impact in networks where the nodes


           that perf=
orm server selections do not support the mechanism.


 


 


 


   REQ 17: In a mixed environment with nodes that support th=
e solution


           and nodes=
 that do not, the solution MUST NOT result in


           materiall=
y less useful throughput during overload as would


           have resu=
lted if the solution were not present.  It SHOULD


           result in=
 less severe overload in this environment.


 


           *Complian=
t*. 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 tha=
t do not, the solution MUST NOT preclude elements


           that supp=
ort overload control from treating elements that do


           not suppo=
rt overload control in an equitable fashion relative


           to those =
that do.  Users and operators of nodes that do not


           support t=
he solution MUST NOT unfairly benefit from the


           solution.=
  The solution specification SHOULD provide guidance


           to implem=
entors for dealing with elements not supporting


           overload =
control.


 


           *Complian=
t*. DOIC provides mechanisms to abate load from non-


           supportin=
g sources.  Furthermore, it recommends that


           reporting=
 nodes will still need to be able to apply whatever


           protectio=
ns they would ordinarily apply if DOIC were not in


           use.=



 


 


 


   REQ 19: It MUST be possible to use the solution between n=
odes in


           different=
 realms and in different administrative domains.


 


           *Partiall=
y Compliant*. DOIC allows sending OLRs across


           administr=
ative domains, and potentially to nodes in other


           realms.&n=
bsp; However, an OLR cannot indicate overload for realms


           other tha=
n the one in the Origin-Realm AVP of the containing


           answer.


 


 


 


   REQ 20: Any explicit overload indication MUST be clearly<=
o:p>


           distingui=
shable from other errors reported via Diameter.


 


           *Complian=
t*. 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 overlo=
aded that it


           cannot pr=
ocess messages, or cannot communicate due to a


           network f=
ailure, it may not be able to provide explicit


           indicatio=
ns of the nature of the failure or its levels of


           overload.=
  The solution MUST result in at least as much


           useful th=
roughput as would have resulted if the solution were


           not in pl=
ace.


 


           *Complian=
t*. DOIC overload reports have the primary effect of


           suppressi=
ng message retries in overload conditions.  DOIC


           recommend=
s 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 thr=
ottle the


           amount of=
 traffic it receives from a peer node.  This


           throttlin=
g SHOULD be graded so that it can be applied


           gradually=
 as offered load increases.  Overload is not a


           binary st=
ate; there may be degrees of overload.


 


           *Complian=
t*. The "loss" algorithm expresses a percentage


           reduction=
.


 


 


 


   REQ 23: The solution MUST provide sufficient information =
to enable a


           load-bala=
ncing 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 Comp=
liant*. 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 &q=
uot;load" extension, or with proprietary load balancing

           mechanism=
s.


 


[M=
Cruz] Partly Compliant. DOIC Overload information can be used already by pr=
oprietary load-balancing implementations.


Lo=
ad information will be a plus to this.


 


 


   REQ 24: The solution MUST pro=
vide a mechanism for indicating load


           levels, e=
ven when not in an overload condition, to assist


           nodes in =
making decisions to prevent overload conditions from


           occurring=
.


 


           *Not Comp=
liant*. "Load" information has been left for a


           future ex=
tension.


 


 


 


C.6.5.  Priority and Policy


 


   REQ 25: The base specification for the solution SHOULD of=
fer general


           guidance =
on which message types might be desirable to send or


           process o=
ver others during times of overload, based on


           applicati=
on-specific considerations.  For example, it may be


           more bene=
ficial to process messages for existing sessions


           ahead of =
new sessions.  Some networks may have a requirement


           to give p=
riority to requests associated with emergency


           sessions.=
  Any normative or otherwise detailed definition of


           the relat=
ive priorities of message types during an overload


           condition=
 will be the responsibility of the application


           specifica=
tion.


 


           *Complian=
t*. The specification offers guidance on how


           requests =
might be prioritized for different types of


           applicati=
ons.


 


 


 


   REQ 26: The solution MUST NOT prevent a node from priorit=
izing


           requests =
based on any local policy, so that certain requests


           are given=
 preferential treatment, given additional


           retransmi=
ssion, not throttled, or processed ahead of others.


 


           *Complian=
t*. Nothing in the specification prevents


           applicati=
on-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


           vulnerabi=
lities.  This includes vulnerabilities to DoS and


           DDoS atta=
cks as well as replay and man-in-the-middle attacks.


           Note that=
 the Diameter base specification [RFC6733] lacks


           end-to-en=
d security and this must be considered (see the


           Security =
Considerations in [RFC7068]).  Note that this


           requireme=
nt 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.


 


           *Complian=
t*. The working group is not aware of any such


           vulnerabi=
lities.  [This may need further analysis.]


 


 


 


   REQ 28: The solution MUST NOT depend on being deployed in=



           environme=
nts where all Diameter nodes are completely trusted.


           It SHOULD=
 operate as effectively as possible in environments


           where oth=
er nodes are malicious; this includes preventing


           malicious=
 nodes from obtaining more than a fair share of


           service.&=
nbsp; Note that this does not imply any responsibility on


           the solut=
ion to detect, or take countermeasures against,


           malicious=
 nodes.


 


           *Partiall=
y Compliant*. Since all Diameter security is


           currently=
 at the transport layer, nodes must trust immediate


           peers to =
enforce trust policies.  However, there are


           situation=
s where a DOIC node cannot determine if an immediate


           peer supp=
orts DOIC.  The authors recommend an expert security


           review.


 


 


 


   REQ 29: It MUST be possible for a supporting node to make=



           authoriza=
tion decisions about what information will be sent


           to peer n=
odes 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


           informati=
on.  Of course, in such cases, there is no


           expectati=
on that the solution itself will help prevent


           overload =
from that peer node.


 


           *Partiall=
y Compliant*. (See response to previous


           requireme=
nt.)


 


 


 


   REQ 30: The solution MUST NOT interfere with any Diameter=
-compliant


           method th=
at a node may use to protect itself from overload


           from non-=
supporting nodes or from denial-of-service attacks.


 


           *Complian=
t*. The specification recommends that any such


           protectio=
n mechanism needed without DOIC should continue to


           be employ=
ed with DOIC.


[MCruz] Could you point o=
ur where in the draft it is described?


 


 


C.6.7.  Flexibility and Extensibility


 


   REQ 31: There are multiple situations where a Diameter no=
de may be


           overloade=
d for some purposes but not others.  For example,


           this can =
happen to an agent or server that supports multiple


           applicati=
ons, 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 indica=
te overload with sufficient granularity to allow


           clients t=
o take action based on the overloaded resources


           without u=
nreasonably forcing available capacity to go unused.


           The solut=
ion MUST support specification of overload


           informati=
on with granularities of at least "Diameter node",

           "rea=
lm", and "Diameter application" and MUST allow

           extensibi=
lity for others to be added in the future.


 


           *Partiall=
y Compliant*. All DOIC overload reports are scoped


           to the sp=
ecific application and realm.  Inside that scope,


           overload =
can be reported at the specific server or whole


           realm sco=
pe.  As currently specified, DOIC cannot indicate


           local ove=
rload for an agent.  At the time of this writing,


           the DIME =
working group has plans to work on an agent-overload


           extension=
.


 


           DOIC allo=
ws new "scopes" through the use of extended report

           types.


 


 


 


   REQ 32: The solution MUST provide a method for extending =
the


           informati=
on communicated and the algorithms used for overload


           control.<=
o:p>


 


           *Complian=
t*. DOIC allows new report types and abatement


           algorithm=
s to be created.  These may be indicated using the


           OC-Suppor=
ted-Features AVP.


 


 


 


   REQ 33: The solution MUST provide a default algorithm tha=
t is


           mandatory=
 to implement.


 


           *Complian=
t*. The "loss" algorithm is mandatory to implement.

 


 


 


   REQ 34: The solution SHOULD provide a method for exchangi=
ng overload


           and load =
information between elements that are connected by


           intermedi=
aries that do not support the solution.


 


           *Partiall=
y Compliant*. DOIC information can traverse non-


           supportin=
g agents, as long as those agents do not modify


           certain A=
VPs. (e.g., Origin-Host).  DOIC does not provide a


           way for s=
upporting nodes to detect such modification.






 










--_000_087A34937E64E74E848732CFF8354B920987F783ESESSMB101erics_--


From nobody Wed Dec 10 07:09:45 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561831A0047 for ; Wed, 10 Dec 2014 07:09:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cXtxRG1LMa1 for ; Wed, 10 Dec 2014 07:09:33 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623E01A02BE for ; Wed, 10 Dec 2014 07:09:23 -0800 (PST)
X-AuditID: c1b4fb3a-f79116d000000fec-9f-54886222d820
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 5A.4F.04076.22268845; Wed, 10 Dec 2014 16:09:22 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.41]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 16:09:21 +0100
From: Maria Cruz Bartolome 
To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Steve Donovan" , "dime@ietf.org" 
Thread-Topic: [Dime] Ulrich suggested change number 1
Thread-Index: AQHQEzn9APTOpOEpnEOsWl042ZAFN5yHKxAQgAGJnHA=
Date: Wed, 10 Dec 2014 15:09:21 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920987F7A8@ESESSMB101.ericsson.se>
References: <54862C38.1000403@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152350CF@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668152350CF@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvja5SUkeIwZQzIhZze1ewWWxo4rFY 93YFkwOzx5IlP5k8fq6/yu6x6m0fawBzFJdNSmpOZllqkb5dAlfG9ms3GAuWyFUsvLuZqYFx u0QXIyeHhICJxIp3+xkhbDGJC/fWs3UxcnEICRxhlOhd+JIJwlnMKNG8/AArSBWbgJ3EpdMv wBIiAv2MEkeuTmACSQgDjTo+cwvQKA6ghKnEhVn5IGERASuJ7lU3wHpZBFQlzt67BmbzCvhK zDuxFswWEiiWeH7yIZjNKRAgsax5O9hIRqCLvp9aA2YzC4hL3HoynwniUgGJJXvOM0PYohIv H/9jhbCVJBbd/gxVrydxY+oUNghbW2LZwtfMEHsFJU7OfMIygVF0FpKxs5C0zELSMgtJywJG llWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsYgbFzcMtvqx2MB587HmIU4GBU4uEteN8eIsSa WFZcmXuIUZqDRUmcd+G5ecFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGB1dtJb5pylciuie Xj/3tn29bJL5gT96sut2b9C8skBOeNGyJ9IbUyZej3nyOOd1ibTs3sdNhirTHl/TvjD9RfZL RkuHSBMdayb7fVs97/E/qN7xJFPsH5P/1OfX8l1N2z5MM3rwaunc36cPHLAz/f3QTfi62bTA lDvnPrIeyqlbHVOttkOK4bASS3FGoqEWc1FxIgD9hyUTfgIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/jVZ0NLGVLgNgQe9KX2Sft2De5jM
Subject: Re: [Dime] Ulrich suggested change number 1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 15:09:36 -0000

Steve, Ulrich,

I agree with proposed changed by Ulrich.
I am in line with his explanations below.

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, December 08, 2014 11:55 PM
To: dime@ietf.org
Subject: [Dime] Ulrich suggested change number 1

Ulrich,

I'll deal with each of your suggestion in a separate email to help ensure t=
hat nothing is missed.

For your first suggestion:
Section 3, last paragraph:
Existing text:
   While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
   that are "adjacent" for DOIC purposes may not be adjacent from a
   Diameter, or transport, perspective.  For example, one or more
   Diameter agents that do not support DOIC may exist between a given
   pair of reporting and reacting nodes, as long as those agents pass
   unknown AVPs through unchanged.  The report types described in this
   document can safely pass through non-supporting agents.  This may not
   be true for report types defined in future specifications.

Comment: while this is all not wrong, the existing text may convey the erri=
ng impression that there cannot be a DOIC supporting agent on the path betw=
een a reporting node and an adjacent reacting node.=20

Proposal: It is proposed to add the following sentence at the end of the pa=
ragraph:
   Another example is where one or more Diameter agents that do support
   DOIC may exist between a given pair of reporting and reacting nodes,
   as long as those agents pass OC-specific AVPs through unchanged.
I don't agree with the suggested change, as the DOIC supporting agents migh=
t need to change the OC-specific AVPs.
 I agree that in some cases DOIC supporting agents need to change t=
he OC-specific AVPs. However, there are also cases where DOIC supporting ag=
ents do not need to change OC-specific AVPs.
=A0 I also don't understand how the paragraph implies that there cannot be =
DOIC supporting agents in the path of the request.
 It does not imply that. Rather it may convey the erring impression=
 that there cannot be a DOIC supporting agent on the path between a reporti=
ng node and an adjacent reacting node.
 =A0 It is talking specifically about the case where there agents do not su=
pport DOIC are in the path.
 No, my understanding is that the paragraph is talking specifically=
 about what "adjacent for DOIC purposes" means. One valid example is given =
(reporting node and reacting node are "adjacent for DOIC purposes" if one o=
r more agents that do not support DOIC but pass unsupported AVPs through un=
changed exist between reporting node and reacting node) and I do not propos=
e to remove that. However, there is another important valid example (report=
ing node and reacting node are "adjacent for DOIC purposes" if one or more =
DOIC supporting agents that pass OC-specific AVPs through unchanged exist b=
etween reporting node and reacting node), and the proposal is to add text t=
o cover this example.  The remainder of the document makes it clea=
r that there can be agents that do support DOIC in the path of a transactio=
n.
 that is not my point. The point is to clearly state that there can=
 be DOIC supporting agents that pass through OC-specific AVPs unchanged on =
the path between reporting node and reacting node, and in this case the rep=
orting and reacting nodes are still regarded "adjacent for DOIC purposes".<=
/Ulrich> =20

I don't see the need for a change here.
 I'm not proposing a modification but an addition. This addition pr=
ovides useful clarification and in no way is harmful

Regards,

Steve

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Dec 10 07:09:46 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482361A0047 for ; Wed, 10 Dec 2014 07:09:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlFZnk25bF4t for ; Wed, 10 Dec 2014 07:09:35 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697ED1A1A7B for ; Wed, 10 Dec 2014 07:09:23 -0800 (PST)
X-AuditID: c1b4fb30-f79d66d00000744c-c9-548862217c95
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id DB.64.29772.12268845; Wed, 10 Dec 2014 16:09:21 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.41]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 16:09:20 +0100
From: Maria Cruz Bartolome 
To: "lionel.morand@orange.com" , Jouni , "dime@ietf.org list" 
Thread-Topic: Call for WG adoption: draft-donovan-dime-agent-overload
Thread-Index: AQHQDuesc80u5oIrU027Q9q+mcP6KZyIvDXw
Date: Wed, 10 Dec 2014 15:09:20 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920987F79E@ESESSMB101.ericsson.se>
References: <32615952-7107-45B6-85AD-AD9F57FBE418@gmail.com> <24870_1417604127_547EEC1F_24870_1587_1_6B7134B31289DC4FAF731D844122B36E99A707@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <24870_1417604127_547EEC1F_24870_1587_1_6B7134B31289DC4FAF731D844122B36E99A707@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvja5iUkeIQddpTYu5vSvYLPava2Cy uL0904HZY+esu+weS5b8ZPJoeXaSLYA5issmJTUnsyy1SN8ugSvjSssexoKjghV7ll5lamC8 ztfFyMEhIWAiMXmHWBcjJ5ApJnHh3nq2LkYuDiGBI4wSLW+boJzFjBKvzv1iBqliE7CTuHT6 BROILSLQyCjxokUNxBYWcJF4/LidBWSoiICrxNL90RAlRhJNf2azgtgsAqoSh9bcBRvDK+Ar ce3WKlaI+TsYJXonXWYHcTgF2hglFn1oYgepYgQ66fupNWDLmAXEJW49mc8EcaqAxJI955kh bFGJl4//sULYShKLbn+GqteTuDF1ChuErS2xbOFrqM2CEidnPmGZwCg6C8nYWUhaZiFpmYWk ZQEjyypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwNg5uOW3wQ7Gl88dDzEKcDAq8fAWvG8P EWJNLCuuzD3EKM3BoiTOu/DcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjPVH7ihwuFyt eHvaPvTRocypjPPZf92Ts5eYPKs3c4JYvvvqm+d7N9SHVBjeunpO+G/DjWWyS+2+ztup7RKm eiSqzd0j76zNLSfZO5tmCt1r//W1pvb3/d7VrpPFG/wtr+6sf+zpGtg1cVXvrmuWRxbFqe8r eeO6Jf12+eJrwsf3bK0oUdVRtVFiKc5INNRiLipOBABD0GKLfgIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/y2jtJL6VUxy013nV6RdgagOhTDc
Subject: Re: [Dime] Call for WG adoption: draft-donovan-dime-agent-overload
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 15:09:38 -0000

Dear all,

I support adoption.
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange=
.com
Sent: mi=E9rcoles, 03 de diciembre de 2014 11:55
To: Jouni; dime@ietf.org list
Subject: Re: [Dime] Call for WG adoption: draft-donovan-dime-agent-overload

As individual, I support.

Lionel

-----Message d'origine-----
De=A0: Jouni [mailto:jouni.nospam@gmail.com] Envoy=E9=A0: mercredi 3 d=E9ce=
mbre 2014 11:12 =C0=A0: dime@ietf.org list Cc=A0: MORAND Lionel IMT/OLN; Jo=
uni Objet=A0: Call for WG adoption: draft-donovan-dime-agent-overload

Folks,

As we discussed and agreed during the Honolulu meeting we ask for the WG ad=
option for draft-donovan-dime-agent-overload unless counter proposals show =
up. The "wait period" for counter proposals has been more than enough.

This mail starts a two week adoption call for draft-donovan-dime-agent-over=
load as a WG Item.

Express your support or disagreements in the mailing list. The call ends 17=
th Dec EOB (CET+1).

- Jouni & Lionel


___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te 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
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Dec 10 07:09:56 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2B41A6FD2 for ; Wed, 10 Dec 2014 07:09:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMVAQk5O6iun for ; Wed, 10 Dec 2014 07:09:38 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DA491A1B2A for ; Wed, 10 Dec 2014 07:09:24 -0800 (PST)
X-AuditID: c1b4fb30-f79d66d00000744c-d6-548862232959
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 9D.64.29772.32268845; Wed, 10 Dec 2014 16:09:23 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.41]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 16:09:23 +0100
From: Maria Cruz Bartolome 
To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Steve Donovan" , "dime@ietf.org" 
Thread-Topic: [Dime] Ulrich suggested change number 3
Thread-Index: AQHQEzuyHw34kXDxv0iSafX1rpswJ5yHTSnAgAFp5/A=
Date: Wed, 10 Dec 2014 15:09:22 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920987F7B0@ESESSMB101.ericsson.se>
References: <54862F13.1060907@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235158@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815235158@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvja5yUkeIwerlIhZze1ewWWxo4rFY 93YFkwOzx5IlP5k8fq6/yu6x6m0fawBzFJdNSmpOZllqkb5dAlfGorbFbAVXJStmtP9jb2Bc LNLFyMkhIWAi8eLAHFYIW0ziwr31bF2MXBxCAkcYJZb/vs8I4SxmlJhyfwFYFZuAncSl0y+Y QBIiAv2MEkeuTmACSQgDjTq3bzeYLSJgKrH+bB8bhG0lcefxMrBmFgFViZ3X9zKD2LwCvhKL Fl5lB7GFBIolbs/ZwgJicwoESPxobQKLMwKd9P3UGrCZzALiEreezGeCOFVAYsme88wQtqjE y8f/oF5Qklh0+zNUvZ7EjalT2CBsbYllC19D7RWUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZ VjGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIERs/BLb8NdjC+fO54iFGAg1GJh7fgfXuIEGti WXFl7iFGaQ4WJXHehefmBQsJpCeWpGanphakFsUXleakFh9iZOLglGpgnF+x5WDh5WzRR/65 VezVtXvX/3oQmfOn2+W3rd/naclTP56YVObzs2Ri2fpbxVcWybFsPH3/253GYMdJWU1CKX7n 1/1oOuv3JdXjdmbYm8MhB1wFVFa8ZZhlYLtQzG+BK6eu3Ib+6G+Fm8p5js6TOjxtT/uF78c6 HfzOeE3blnnJ0SFtYsGqhUosxRmJhlrMRcWJADDuLnF/AgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Zfw4yeiFQKUfWZYgMusEnP18FRY
Subject: Re: [Dime] Ulrich suggested change number 3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 15:09:40 -0000

Steve, Ulrich,

I am fine with modification agreement.
Thanks
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: martes, 09 de diciembre de 2014 15:31
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Ulrich suggested change number 3

Steve,

please see inline.

Ulrich


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 09, 2014 12:07 AM
To: dime@ietf.org
Subject: [Dime] Ulrich suggested change number 3

Ulrich,

For suggested change number 3:
Section 3.2, last two paragraphs:
Existing text:
   The DCA mechanism must also allow the scenario where the set of
   features supported by the sender of a request and by agents in the
   path of a request differ.  In this case, the agent updates the OC-
   Supported-Features AVP to reflect the mixture of the two sets of
   supported features.

      Note: The logic to determine the content of the modified  OC-
      Supported-Features AVP is out-of-scope for this specification and
      is left to implementation decisions.  Care must be taken not to
      introduce interoperability issues for downstream or upstream DOIC
      nodes.

Comment: It is perfectly ok (in this case) for the agent not to update and =
not to modify.=20

Proposal: It is proposed to replace the two paragraphs with the following:
   The DCA mechanism must also allow the scenario where the set of
   features supported by the sender of a request and by agents in the
   path of a request differ.  In this case, the agent can update the OC-
   Supported-Features AVP to reflect the mixture of the two sets of
   supported features.

      Note: The logic to determine whether and if how to modify the
      content of the OC-Supported-Features AVP is out-of-scope for this
      specification and is left to implementation decisions.  Care must
      be taken not to introduce interoperability issues for downstream
      or upstream DOIC nodes.
I don't see the need for the change as the paragraph is talking specificall=
y about the scenario where an agent would change the OC-Supported-Features =
AVP.
 I do not agree. The paragraph is talking specifically about the ca=
se where the set of features supported by the sender of a request and by ag=
ents in the path of a request differ. In this case it is certainly true tha=
t the agent can update (modify, change) the OC-Supported-Features AVP. It i=
s, however, also true that in this case the agent can choose not to update.=
 That said, the change in the first paragraph is ok.
 thank you 
If we make that change then I suggest a cleaned up first sentence of the ne=
xt paragraph as follows:

"Note: The logic to determine if the content of the=A0 OC-Supported-Feature=
s AVP should be changed is out-of-scope for this document, as is the logic =
to determine the content of a modified OC-Supported-Features AVP.=A0 These =
are left to implementation decisions..."
 The clean up is fine

Regards,

Steve

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Dec 10 07:09:58 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1366A1A6FEF for ; Wed, 10 Dec 2014 07:09:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjVeQ1KbSTTP for ; Wed, 10 Dec 2014 07:09:38 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C77B1A3B9D for ; Wed, 10 Dec 2014 07:09:24 -0800 (PST)
X-AuditID: c1b4fb3a-f79116d000000fec-a6-548862246d77
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 6B.4F.04076.42268845; Wed, 10 Dec 2014 16:09:24 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.41]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 16:09:23 +0100
From: Maria Cruz Bartolome 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Ulrich suggested change number 4
Thread-Index: AQHQE658JlNue1qo10W5Gt9YB0I+bJyItskw
Date: Wed, 10 Dec 2014 15:09:23 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920987F7B8@ESESSMB101.ericsson.se>
References: <5486EFAA.7090902@usdonovans.com>
In-Reply-To: <5486EFAA.7090902@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920987F7B8ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvja5KUkeIwbw+YYu5vSvYLDY08Tgw eSxZ8pPJY9XbPtYApigum5TUnMyy1CJ9uwSujF2/3rAWnLarONl0gqWB8ZlpFyMnh4SAicTU deeZIWwxiQv31rN1MXJxCAkcYZRY9X83O4SzmFHizfGDTCBVbAJ2EpdOvwCzRQR8JY53nmYB sYWBJu09vpUFIm4qsWTDQlYI20ji68/ZbCA2i4CqxJJ9h8F6eYF6n148zghiCwnoSrxt/AdW wymgJ3Ht8muwXkagi76fWgNWzywgLnHryXwmiEsFJJbsgblaVOLl43+sELaSxKLbn6Hq8yWe Tl/LArFLUOLkzCcsExhFZiEZNQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0V o2hxanFxbrqRkV5qUWZycXF+nl5easkmRmBcHdzy22oH48HnjocYBTgYlXh4C963hwixJpYV V+YeYpTmYFES5114bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsZJAmzcR+QNpd5Z8dsf MtjLsmeGzxTlGOmvUVtdTq7/c29tUL4027Ifm7ntTh+paHzw1zeH/3xOkhNLgculBGO5tbwT iv7Y2/rtZmZf85irXXmTjNjF64ocf0qTi9ZLHJ2yLuTvnlW+v2fFJR08vFLV7nGz0FG762bW x3w5Xyt9V5NO2/V+YZcSS3FGoqEWc1FxIgC50bERjAIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/s-AvlRpjxOrUEwNmpOzc1Tjk5eQ
Subject: Re: [Dime] Ulrich suggested change number 4
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 15:09:41 -0000

--_000_087A34937E64E74E848732CFF8354B920987F7B8ESESSMB101erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I agree
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: martes, 09 de diciembre de 2014 13:49
To: dime@ietf.org
Subject: [Dime] Ulrich suggested change number 4

Ulrich,

For your fourth suggested change:

Section 3.3, 4th and 5th paragraph:

Existing text:

   A report of type "HOST_REPORT" is sent to indicate the overload of a

   specific Diameter node for the application-id indicated in the

   transaction.  When receiving an OLR of type host, a reacting node

   applies overload abatement to what is referred to in this document as

   host-routed requests.  The reacting node applies overload abatement

   on those host-routed requests which the reacting node knows will be

   served by the server that matches the Origin-Host AVP of the received

   message that contained the received OLR of type host.



   A report of type "REALM_REPORT" applies to realm-routed requests for

   a specific realm as indicated in the Destination-Realm AVP.

Comment: While the 4th paragraph is all fine, the 5th paragraph should be a=
ligned.

Proposal: It is proposed to replace the 5th paragraph with:

   A report of type "REALM_REPORT" is sent to indicate the overload of all

   Diameter nodes within a realm for the application-id indicated in the

   transaction.  When receiving an OLR of type realm, a reacting node

   applies overload abatement to what is referred to in this document as

   realm-routed requests.  The reacting node applies overload abatement

   on those realm-routed requests which contain  a Destination-Realm AVP

   that matches the Origin-Realm AVP of the received message that

   contained the received OLR of type realm.
I support the suggested change.

Regards,

Steve


--_000_087A34937E64E74E848732CFF8354B920987F7B8ESESSMB101erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I agree



/MCruz<=
/p>

 <=
/p>





From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of Steve Donovan

Sent: martes, 09 de diciembre de 2014 13:49

To: dime@ietf.org

Subject: [Dime] Ulrich suggested change number 4





 


Ulrich,



For your fourth suggested change:


Section 3.3, 4th and 5th paragraph:


Existing text:


   A report of type "HOST_REPORT" is sent to indic=
ate the overload of a


   specific Diameter node for the application-id indicated i=
n the


   transaction.  When receiving an OLR of type host, a =
reacting node


   applies overload abatement to what is referred to in this=
 document as


   host-routed requests.  The reacting node applies ove=
rload abatement


   on those host-routed requests which the reacting node kno=
ws will be


   served by the server that matches the Origin-Host AVP of =
the received


   message that contained the received OLR of type host.


 


   A report of type "REALM_REPORT" applies to real=
m-routed requests for


   a specific realm as indicated in the Destination-Realm AV=
P.


Comment: While the 4th paragraph is all fine, the 5th paragraph should=
 be aligned.


Proposal: It is proposed to replace the 5th paragraph with:=



   A report of type "REALM_REPORT" is sent to indi=
cate the overload of all


   Diameter nodes within a realm for the application-id indi=
cated in the


   transaction.  When receiving an OLR of type realm, a=
 reacting node


   applies overload abatement to what is referred to in this=
 document as


   realm-routed requests.  The reacting node applies ov=
erload abatement


   on those realm-routed requests which contain  a Dest=
ination-Realm AVP


   that matches the Origin-Realm AVP of the received message=
 that


   contained the received OLR of type realm.

I support the suggest=
ed change.



Regards,



Steve










--_000_087A34937E64E74E848732CFF8354B920987F7B8ESESSMB101erics_--


From nobody Wed Dec 10 07:09:59 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC9E1A6FD2 for ; Wed, 10 Dec 2014 07:09:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7bfKCuvcKSj for ; Wed, 10 Dec 2014 07:09:41 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0BA01A6F2F for ; Wed, 10 Dec 2014 07:09:26 -0800 (PST)
X-AuditID: c1b4fb3a-f79116d000000fec-ad-54886226ae2d
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 3C.4F.04076.62268845; Wed, 10 Dec 2014 16:09:26 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.41]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 16:09:26 +0100
From: Maria Cruz Bartolome 
To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Steve Donovan" , "dime@ietf.org" 
Thread-Topic: [Dime] Ulrich's suggested change #7
Thread-Index: AQHQE7D4grL00xcS/0y1e/ob6rXZ/JyHQqWAgAF1yAA=
Date: Wed, 10 Dec 2014 15:09:25 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920987F7C8@ESESSMB101.ericsson.se>
References: <5486F3D7.7040305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235171@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815235171@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvja5aUkeIwey74hZze1ewWWxo4rFY 93YFkwOzx5IlP5k8fq6/yu6x6m0fawBzFJdNSmpOZllqkb5dAlfGhce3WQsmcFfM7Z/D2MDY xtnFyMkhIWAicWxaDyuELSZx4d56ti5GLg4hgSOMEvsOz2UHSQgJLGaUeHvWD8RmE7CTuHT6 BRNIkYhAP6PEkasTmEASwgIGEicWHGTsYuQAShhKvHmRBRIWEbCSePr6KhuIzSKgKtHYdxts Ga+Ar8TyB9eYIOYXS5zoPQYW5xQIkHi9qp0FxGYEOuj7qTVgNcwC4hK3nsxngjhUQGLJnvPM ELaoxMvH/6AeUJJYdPszVL2OxILdn9ggbG2JZQtfM0PsFZQ4OfMJywRG0VlIxs5C0jILScss JC0LGFlWMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgRGzsEtv612MB587niIUYCDUYmHt+B9 e4gQa2JZcWXuIUZpDhYlcd6F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDM73dj2Wyo WaEU9X2Ope2uDxeCnb//5rn7MkZk/6Oi0xkFzKdUjoawZFionfT43B/idz60YH/Du2lzJetW 6p/oO5v04/d7wcp/IdtZi5dNmPfE9NK3xQsSL03pvrE8yCBmnuaq8I3LrCT31juw57MfF1k6 y0Y17Y5Q6Bptu/glSYJXpv3qmHxUiaU4I9FQi7moOBEAeX5T/n0CAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/HUecy6oL239SweBs8MdCRk1pHo0
Subject: Re: [Dime] Ulrich's suggested change #7
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 15:09:43 -0000

Fine with me
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: martes, 09 de diciembre de 2014 15:36
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Ulrich's suggested change #7

Steve,

please see inline.

Ulrich


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 09, 2014 2:07 PM
To: dime@ietf.org
Subject: [Dime] Ulrich's suggested change #7

Ulrich,

For your suggested change #7:
Section 4.1.2, 4th paragraph:
Existing text:
   A reporting node knows what overload control functionality is
   supported by the reacting node based on the content of the OC-
   Feature-Vector AVP in the request message.
Comment: The Feature-Vector AVP may be absent. In this case knowledge canno=
t be based on the content.
Proposal: Replace the paragraph with:
   A reporting node knows what overload control functionality is
   supported by the reacting node based on the content or absence of
   the OC-Feature-Vector AVP within the Supported-Features AVP in the
   request message.
I support the change with the modification of Supported-Features to OC-Supp=
orted-Features.
 fine with me

Regards,

Steve

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Dec 10 07:10:01 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C1A1A6F2F for ; Wed, 10 Dec 2014 07:09:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ketfQATZMdjA for ; Wed, 10 Dec 2014 07:09:40 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA4091A6F12 for ; Wed, 10 Dec 2014 07:09:25 -0800 (PST)
X-AuditID: c1b4fb30-f79d66d00000744c-de-54886225ad54
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CE.64.29772.52268845; Wed, 10 Dec 2014 16:09:25 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.41]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 16:09:24 +0100
From: Maria Cruz Bartolome 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Ulrich suggested change number 5
Thread-Index: AQHQE68GCcS3l2M5okuebV1UmT60rJyIt06w
Date: Wed, 10 Dec 2014 15:09:24 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920987F7C0@ESESSMB101.ericsson.se>
References: <5486F07D.1010102@usdonovans.com>
In-Reply-To: <5486F07D.1010102@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920987F7C0ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvja5qUkeIwZ3LshZze1ewWWxo4nFg 8liy5CeTx6q3fawBTFFcNimpOZllqUX6dglcGWt3f2QuOGxesXzNPMYGxgkGXYwcHBICJhLP FgCZnECmmMSFe+vZuhi5OIQEjjBK3F36ih3CWcwoce3JU3aQKjYBO4lLp18wgdgiAr4SxztP s4DYwkCDJuy7zQIyVETAVOJcdyJEiZHEs4bnYCUsAqoSh04vYAaxeYFaH7fOYwSxhQR0Jfa/ Pwc2klNAT2L/r61gqxiBDvp+ag1YnFlAXOLWk/lMEIcKSCzZc54ZwhaVePn4HyuErSSx6PZn qPp8iWNnv7BA7BKUODnzCcsERpFZSEbNQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceMyGL L2BkX8UoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGFMHt/w22MH48rnjIUYBDkYlHt6C9+0h QqyJZcWVuYcYpTlYlMR5F56bFywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB0c9Xm62o4emJ Qr77wTtUAn7eP/xN89DHRuPuTLNFGXfTb98StQjdxzz3mKkFz4sdhYe3pVjk7M+QlTLxkK1z WveklWnpW+YbMwurDnyoVj8YnCHYmXO2aMr+Em191+SDcxcvctVnOm+d9kfixttlfL93ZDDO 7X+z/vxE8YOWPQqyAr4vP0VOV2Ipzkg01GIuKk4EAO+DyRqKAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/P85JrywxEvPnkklKeunbS20o828
Subject: Re: [Dime] Ulrich suggested change number 5
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 15:09:46 -0000

--_000_087A34937E64E74E848732CFF8354B920987F7C0ESESSMB101erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Fine
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: martes, 09 de diciembre de 2014 13:52
To: dime@ietf.org
Subject: [Dime] Ulrich suggested change number 5

Ulrich,

For your suggested change number 5:

Section 3.3, 8th paragraph:

Existing text:

   Reporting nodes are responsible for determining the need for a

   reduction of traffic.  The method for making this determination is

   implementation specific and depend on the type of overload report

   being generated.  A host-report, for instance, will generally be

   generated by tracking utilization of resources required by the host

   to handle transactions for the Diameter application.  A realm-report

   generally impacts the traffic sent to multiple hosts and, as such,

   requires tracking the capacity all servers for realm-routed requests

   for the application and realm.

Comment: Something is wrong with the last sentence.

Proposal: Replace the last sentence with:

                                                         A realm-report

   generally impacts the traffic sent to multiple hosts and, as such,

   requires tracking the capacity of all servers able to handle realm-

   routed requests for the application and realm.

I support the change.

Regards,

Steve

--_000_087A34937E64E74E848732CFF8354B920987F7C0ESESSMB101erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Fine

/MCruz<=
/p>

 <=
/p>





From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of Steve Donovan

Sent: martes, 09 de diciembre de 2014 13:52

To: dime@ietf.org

Subject: [Dime] Ulrich suggested change number 5





 


Ulrich,



For your suggested change number 5:


Section 3.3, 8th paragraph:


Existing text:


   Reporting nodes are responsible for determining the need =
for a


   reduction of traffic.  The method for making this de=
termination is


   implementation specific and depend on the type of overloa=
d report


   being generated.  A host-report, for instance, will =
generally be


   generated by tracking utilization of resources required b=
y the host


   to handle transactions for the Diameter application. =
; A realm-report


   generally impacts the traffic sent to multiple hosts and,=
 as such,


   requires tracking the capacity all servers for realm-rout=
ed requests


   for the application and realm.


Comment: Something is wrong with the last sentence.


Proposal: Replace the last sentence with:


           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;       A realm-report


   generally impacts the traffic sent to multiple hosts and,=
 as such,


   requires tracking the capacity of all servers able to han=
dle realm-


   routed requests for the application and realm.=





I support the change.



Regards,



Steve






--_000_087A34937E64E74E848732CFF8354B920987F7C0ESESSMB101erics_--


From nobody Wed Dec 10 07:10:02 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17F61A6F12 for ; Wed, 10 Dec 2014 07:09:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aOSX1Ijka8f for ; Wed, 10 Dec 2014 07:09:43 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E225D1A6F9F for ; Wed, 10 Dec 2014 07:09:27 -0800 (PST)
X-AuditID: c1b4fb30-f79d66d00000744c-ea-54886227b53f
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 40.74.29772.72268845; Wed, 10 Dec 2014 16:09:27 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.41]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 16:09:26 +0100
From: Maria Cruz Bartolome 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Ulrich's suggested change #11
Thread-Index: AQHQE7WgFE9wft/vFEGkP2TygOAcPpyIvO5g
Date: Wed, 10 Dec 2014 15:09:26 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920987F7D0@ESESSMB101.ericsson.se>
References: <5486FBA8.9020206@usdonovans.com>
In-Reply-To: <5486FBA8.9020206@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920987F7D0ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+Jvja56UkeIwZ61ahZze1ewWWxo4nFg 8liy5CeTx6q3fawBTFFcNimpOZllqUX6dglcGfN/72AvaDKseHXkBFMD426tLkZODgkBE4mf qz8zQthiEhfurWcDsYUEjjBKbJxn18XIBWQvZpTY9/0gWBGbgJ3EpdMvmEBsEQFfieOdp1lA bGEBQ4lpF5exQ8SNJM5veg1UwwFm/9qgBhJmEVCV+H9gLhtImBeo9eRKsAohAV2JGeuTQCo4 BfQkVm9fxgxiMwJd8/3UGrBFzALiEreezGeCuFJAYsme88wQtqjEy8f/WCFsJYlFtz+DjWQW yJfYfaAYJMwrIChxcuYTlgmMIrOQTJqFUDULSRVEiY7Egt2f2CBsbYllC18zw9hnDjxmQhZf wMi+ilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMwlg5u+W2wg/Hlc8dDjAIcjEo8vAXv20OE WBPLiitzDzFKc7AoifMuPDcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjdcQKea9fDEIB jCsWZC0O/DxBOegID0dN9v0fcZ5WM5SDMv4vK5GeouO6NV3jWd96va87TvWk6Wxa+vFl7I4V H6eumTqR1W4nN5fo8nu8b+rtOUK73XaxHLIV35vD7tLUkrTx+fzGiH3lbJP3mQpWhD4P9fz6 Zo/zDYFp/hwpnxP3fL9hbDRfiaU4I9FQi7moOBEARShDLoYCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/zi4nkc1MXpsoMZznwqRgeClNmOU
Subject: Re: [Dime] Ulrich's suggested change #11
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 15:09:46 -0000

--_000_087A34937E64E74E848732CFF8354B920987F7D0ESESSMB101erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Fine

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: martes, 09 de diciembre de 2014 14:40
To: dime@ietf.org
Subject: [Dime] Ulrich's suggested change #11

Ulrich,

For your  suggested change #11:

Section 4.1.3, 6th paragraph:

Existing text:

   As with a Diameter endpoint taking on reporting node behavior, a

   Diameter Agent MUST only include the OC-Supported-Features AVP in

   answer messages for transactions where the request message received

   by the Diameter Agent had an OC-Supported-Features AVP.

Comments: "MUST only do x for condition y" could mean:

a) "MUST do x for condition y and MUST NOT do x for conditions other than y=
", or

b) "MUST do x and nothing else for condition y, and nothing is specified fo=
r conditions other than y".

Proposal: Replace the paragraph with:

   As with a Diameter endpoint taking on reporting node behavior, a

   Diameter Agent MUST NOT include the OC-Supported-Features AVP in

   answer messages for transactions where the request message received

   by the Diameter Agent had no OC-Supported-Features AVP.
I support this change.

Regards,

Steve


--_000_087A34937E64E74E848732CFF8354B920987F7D0ESESSMB101erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Fine

 <=
/p>





From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of Steve Donovan

Sent: martes, 09 de diciembre de 2014 14:40

To: dime@ietf.org

Subject: [Dime] Ulrich's suggested change #11






 


Ulrich,



For your  suggested change #11:


Section 4.1.3, 6th paragraph:


Existing text:


   As with a Diameter endpoint taking on reporting node beha=
vior, a


   Diameter Agent MUST only include the OC-Supported-Feature=
s AVP in


   answer messages for transactions where the request messag=
e received


   by the Diameter Agent had an OC-Supported-Features AVP.


Comments: "MUST only do x for condition y" could mean:<=
/o:p>


a) "MUST do x for condition y and MUST NOT do x for conditions ot=
her than y", or


b) "MUST do x and nothing else for condition y, and nothing is sp=
ecified for conditions other than y".


Proposal: Replace the paragraph with:


   As with a Diameter endpoint taking on reporting node beha=
vior, a


   Diameter Agent MUST NOT include the OC-Supported-Features=
 AVP in


   answer messages for transactions where the request messag=
e received


   by the Diameter Agent had no OC-Supported-Features AVP.


I support this change=
.



Regards,



Steve










--_000_087A34937E64E74E848732CFF8354B920987F7D0ESESSMB101erics_--


From nobody Wed Dec 10 07:54:27 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749531A0115 for ; Wed, 10 Dec 2014 07:54:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElT-n1Q5Pk1L for ; Wed, 10 Dec 2014 07:54:06 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C8A1A7010 for ; Wed, 10 Dec 2014 07:53:30 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBAFrS2q014889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Dec 2014 15:53:28 GMT
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBAFrS7I000978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Dec 2014 16:53:28 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 16:53:27 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Ulrich suggested change number 2
Thread-Index: AQHQEzp/NeYxnYFinESbfvW92bFjMJyHQOiggAFzEACAAEV2MA==
Date: Wed, 10 Dec 2014 15:53:27 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815235452@DEMUMBX014.nsn-intra.net>
References: <54862D14.2060304@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235122@DEMUMBX014.nsn-intra.net> <54883DC2.20504@usdonovans.com>
In-Reply-To: <54883DC2.20504@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 3272
X-purgate-ID: 151667::1418226808-0000658F-C2E325A7/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/sxwy4sOfg91dncq8BLu0ZGbsZ_w
Subject: Re: [Dime] Ulrich suggested change number 2
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 15:54:09 -0000

Steve,

How about something like this:

"This ensures that a reporting node allways supports at least one of the ad=
vertized abatement algorithms received in a request messages."

Regards
Ulrich


-----Original Message-----
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
Sent: Wednesday, December 10, 2014 1:34 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Ulrich suggested change number 2

Ulrich,

How about changing the last sentence to:

"This ensures that there is at least one commonly supported overload=20
abatement algorithm supported by all DOIC nodes in the path of the request.=
"

Regards,

Steve

On 12/9/14, 8:08 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
>
> please see inline.
>
> Ulrich
>
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
> Sent: Monday, December 08, 2014 11:58 PM
> To: dime@ietf.org
> Subject: [Dime] Ulrich suggested change number 2
>
> Ulrich,
>
> For the second suggested change:
> Section 3.2, 6th paragraph:
> Existing text:
>     The OC-Feature-Vector AVP will contain an indication of support for
>     the loss overload abatement algorithm defined in this specification
>     (see Section 5).  This ensures that there is at least one commonly
>     supported overload abatement algorithm between the reporting node and
>     the reacting node(s) in the path of the request.
>
> Comment: I agree that within a given path between client and server there=
 may
> be more than one reacting nodes. But a given reporting node on that path =
does
> not have more than one adjacent reacting nodes on that given path to whic=
h it
> sends OLRs. I don't say that the existing text is wrong, but it is mislea=
ding.
> What we want to say here is that any given pair of adjacent reacting and =
reporting
> nodes will have at least one commonly supported algorithm.
>
> Proposal: It is proposed to replace the last line of the paragraph with:
>     The adjacent reacting node on the path of the request.
> It's more than just about the adjacent reaction nodes.  It is important t=
hat all reacting nodes in the path of the request have at least one common =
abatement algorithm.
> I do not agree. It is important that a pair of two adjacent react=
ing and reporting nodes (A,S) have at least one commonly supported algorith=
m, so that the reporting node can always select an algorithm supported by t=
he adjacent reacting node. There may be another (non-adjacent) reacting nod=
e in the path (C), but its not important for C and S (which are not adjacen=
t) to have a commonly supported algorithm.
> C---A---S
> It is important that C and A have a commonly supported algorith, as C and=
 A are adjacent;
> It is important that A and S have a commonly supported algorith, as A and=
 S are adjacent;
> It is true but not important (and nothing that needs to be ensured) that =
C and S have a commonly supported algorithm (indeed S could eventually sele=
ct an algorithm not supported by C);
> It is true but not important that C, A and S have a commonly supported al=
gorithm.
>
> I don't see the need for the suggested change.
>
> Regards,
>
> Steve
>


From nobody Wed Dec 10 14:02:15 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E7A1A90C1 for ; Wed, 10 Dec 2014 14:02:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZkIW9t0AuE2 for ; Wed, 10 Dec 2014 14:02:03 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6251A90B1 for ; Wed, 10 Dec 2014 14:02:03 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBAM22CW085129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 16:02:02 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5486F0F1.8000200@usdonovans.com>
Date: Wed, 10 Dec 2014 16:02:01 -0600
X-Mao-Original-Outgoing-Id: 439941721.591634-3905282a87a801cb8b7519ccec526854
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5486F0F1.8000200@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/sr8z9i9_ERFjlZYT2-HBnR0g45Y
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggest change number 6
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 22:02:13 -0000

> On Dec 9, 2014, at 6:54 AM, Steve Donovan  =
wrote:
>=20
> Ulrich,
>=20
> For your suggested change #6:
>=20
> Section 3.3, 12th paragraph:
> Existing text:
>    As the conditions that lead to the generation of the overload =
report
>    change the reporting node can send new overload reports requesting
>    greater reduction if the condition gets worse or less reduction if
>    the condition improves.  The reporting node sends an overload =
report
>    with a duration of zero to indicate that the overload condition has
>    ended and need for use of the abatement algorithm to reduce traffic
>    sent is no longer needed.
> Comment: Bad style.
> Proposal: Remove the words "need for" from the last sentence.
>=20
> I support the suggested change.

If we are going to change it, I propose a further simplification of the =
last sentence:

"... and abatement is no longer needed."


From nobody Wed Dec 10 14:07:07 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06731A8755 for ; Wed, 10 Dec 2014 14:07:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqZ1NHG2LAoR for ; Wed, 10 Dec 2014 14:06:57 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C701A8A4C for ; Wed, 10 Dec 2014 14:06:56 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBAM6tS8085583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 16:06:56 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5487050C.8080206@usdonovans.com>
Date: Wed, 10 Dec 2014 16:06:55 -0600
X-Mao-Original-Outgoing-Id: 439942015.285245-f89d0546ae8b108763149754fe43ee9a
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5487050C.8080206@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/6daJg97VLXnxJl7YXiqpaN4HeTE
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich suggested changes 18, 19, 20 and 21
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 22:07:06 -0000

> On Dec 9, 2014, at 8:19 AM, Steve Donovan  =
wrote:
>=20
> Ulrich,
>=20
> I support the suggested changes in your suggested changes 18, 19, 20 =
and 21:
>=20
> Section 4.3, 3rd paragraph:
> Existing text:
>    The extension MAY define new AVPs for use in DOIC Capability
>    Announcement and for use in DOIC Overload reporting.  These new =
AVPs
>    SHOULD be defined to be extensions to the OC-Supported-Features and
>    OC-OLR AVPs defined in this document.
> Comment: It is not necessary for a new AVP to be an extension to both =
the OC-Supported-Features AVP and the OC-OLR AVP.
> Proposal: Replace the paragraph with:
>    The extension MAY define new AVPs for use in DOIC Capability
>    Announcement and for use in DOIC Overload reporting.  These new =
AVPs
>    SHOULD be defined to be extensions to the OC-Supported-Features =
and/or
>    OC-OLR AVPs defined in this document.


"And/or" is an awkward construct. How about just "or"?  I think the =
context makes it pretty clear that it's not "xor".

[...]


From nobody Wed Dec 10 14:57:54 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F1E1AC40E for ; Wed, 10 Dec 2014 14:57:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6CJrcKWV9Q2 for ; Wed, 10 Dec 2014 14:57:49 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 184201AC406 for ; Wed, 10 Dec 2014 14:57:49 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBAMvkDj010057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 16:57:48 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815235197@DEMUMBX014.nsn-intra.net>
Date: Wed, 10 Dec 2014 16:57:46 -0600
X-Mao-Original-Outgoing-Id: 439945066.663541-7ff482f386f4a2489c13b6aeb5439432
Content-Transfer-Encoding: quoted-printable
Message-Id: <57CA5812-ABE6-4974-8632-1BC40FA84082@nostrum.com>
References: <5486F59E.4000908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235197@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7OKkVMvgc8NFJoV45yToq2Yk-9c
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #8
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 22:57:50 -0000

> On Dec 9, 2014, at 9:30 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:
>=20
> Steve,
>=20
> please see inline.
>=20
> Ulrich
>=20
>=20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve =
Donovan
> Sent: Tuesday, December 09, 2014 2:14 PM
> To: dime@ietf.org
> Subject: [Dime] Ulrich's suggested change #8
>=20
> Ulrich,
>=20
> For your suggested change number 8:
> Section 4.1.2, 8th paragraph:
> Existing text:
>   For an ongoing overload condition, a reporting node MUST NOT change
>   the selected algorithm during the period of time that it is in an
>   overload condition and, as a result, is sending OC-OLR AVPs in =
answer
>   messages.
>=20
> Comment: As a result of an ongoing overload condition the reporting =
node is=20
> sending OC-OLR AVPs containing no validity duration or a validity =
duration=20
> different from zero in answer messages.
>=20
> Proposal: Replace the paragraph with:
>   For an ongoing overload condition, a reporting node MUST NOT change
>   the selected algorithm during the period of time that it is in an
>   overload condition and, as a result, is sending OC-OLR AVPs
>   containing no validity duration or a validity duration different
>   from zero in answer messages.
> I don't see the need for the change.  The selected algorithm should =
not change for all overload reports relating to an overload condition, =
including overload reports with a validity duration of zero.
>  Isn't it so that when the overload condition ends (i.e. is no =
longer ongoing), the reporting node starts sending OLRs with validity =
duration of zero (for a long enough period of time)? (see end of section =
4.2.1.4)=20
> The question now is whether the change of algorithm is allowed during =
this (long enough) period, or only after that period. I don't have a =
strong view. But this was not my point.
> My point is that the current text seems to suggest that an overload =
condition is ongoing as long as OC-OLR AVPs are sent in answer messages, =
and I think that is not true. 
>=20

I think the proscription should last until the reporting node is (at =
least reasonably) sure that all reacting nodes have removed the OCS. The =
original text comes closer to that than Ulrich's proposal, but I wonder =
if we shouldn't cast this in similar terms as we do for the part about =
resending zero duration OLRs.


From nobody Wed Dec 10 15:06:09 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02771A1A9E for ; Wed, 10 Dec 2014 15:06:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiQrR8wSOK-J for ; Wed, 10 Dec 2014 15:06:07 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4748E1A1A9D for ; Wed, 10 Dec 2014 15:06:07 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBAN667G010746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 17:06:06 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5486FA8B.6040503@usdonovans.com>
Date: Wed, 10 Dec 2014 17:06:05 -0600
X-Mao-Original-Outgoing-Id: 439945565.681195-2ff3432eb017bb526d1c0634e16bf783
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5486FA8B.6040503@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/44XEMdCKC7C8_t9jn0Se13iUso8
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested changes #9 and #10
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 23:06:08 -0000

> On Dec 9, 2014, at 7:35 AM, Steve Donovan  =
wrote:
>=20
> Ulrich,
>=20
> Suggested changes 9 and 10 are linked so I'll deal with them in a =
single email:
>=20
> Section 4.1.3, 1st paragraph:
> Existing text:
>    Diameter Agents that support DOIC SHOULD ensure that all messages
>    relayed by the agent contain the OC-Supported-Features AVP.
> Comment: The SHOULD in the first line is not correct based on my next =
comment.
> Proposal: Delete the first paragraph.=20
>=20
> Section 4.1.3, 4th paragraph:
> Existing text:
>    A Diameter Agent SHOULD take on reporting node behavior for =
Diameter
>    endpoints that do not support the DOIC solution.  A Diameter Agent
>    detects that a Diameter endpoint does not support DOIC reporting =
node
>    behavior when there is no OC-Supported-Features AVP in an answer
>    message for a transaction that contained the OC-Supported-Features
>    AVP in the request message.
> Comment: The first sentence can reasonably only apply to Diameter =
agents that are immediate peers to the non-supporting Diameter endpoint. =
We cannot expect a far-away-agent to take on reporting node behavior =
when all upstream agents and the server do not support DOIC. =
Furthermore: When the non-supporting server has two DOIC supporting =
immediate peer agents which both take on reporting node behavior we end =
up in problems similar to those identified in the note in section 3.3.
> Proposal:Replace the paragaph with:
>    A Diameter Agent that is an immediate peer to the Diameter endpoint
>    that does not support DOIC SHOULD take on reporting node behavior =
for
>    Diameter endpoints that do not support the DOIC solution.  A =
Diameter
>    Agent detects that a Diameter endpoint does not support DOIC =
reporting
>    node behavior when there is no OC-Supported-Features AVP in an =
answer
>    message for a transaction that contained the OC-Supported-Features
>    AVP in the request message.
>       Note: Known issues exist if multiple sources for overload =
reports
>       which apply to the same Diameter entity exist.  Reacting nodes
>       have no way of determining the source and, as such, will treat
>       them as coming from a single source.  Variance in sequence =
numbers
>       between the two sources can then cause incorrect overload
>       abatement treatment to be applied for indeterminate periods of
>       time.
>=20
> You point out an interesting issue with agents taking on reporting =
node functionality.
>=20
> I don't, however, think that an agent that takes on reporting node =
functionality for a non supporting host needs to be adjacent to the =
host.  The important thing is that it has visibility to all of the =
traffic sent to the host.
>=20
> I suggest keeping the first paragraph but changing the SHOULD to a =
MAY.
>=20
> I also suggest changing the SHOULD to a MAY in the fourth paragraph =
and changing the first sentence to:
>=20
> A Diameter Agent MAY take on reporting node behavior for Diameter =
endpoints that do not support the DOIC solution. =20

I agree with everything up to there. (Not necessarily for the reasons =
given, but I've been pushing for this to be MAY or non-normative for a =
while now :-) )


> The Diameter Agent MUST have visibility to all traffic destined for =
the non supporting host in order to become the reporting node for the =
Diameter endpoint.

I see the issue, but I think that answer needs more thought. It seems to =
disallow the case where you have a pair of agents in an active-active =
configuration in front of a non-supporting server, unless they sync OCS. =
I strongly suspect that case will be the rule, at least for telecom =
deployments.

/Ben=


From nobody Wed Dec 10 15:20:42 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339101AC41E for ; Wed, 10 Dec 2014 15:20:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxB21jxhHNba for ; Wed, 10 Dec 2014 15:20:35 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93ADD1AC41B for ; Wed, 10 Dec 2014 15:20:35 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBANKY6k012009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 17:20:35 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <54883F5C.1060603@usdonovans.com>
Date: Wed, 10 Dec 2014 17:20:34 -0600
X-Mao-Original-Outgoing-Id: 439946434.09916-6e086a2ab21bfec16ec7566804855652
Content-Transfer-Encoding: quoted-printable
Message-Id: <7BF0F726-12CE-4236-8809-6B5E518F393D@nostrum.com>
References: <5486FCBF.4000707@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152351D9@DEMUMBX014.nsn-intra.net> <54883F5C.1060603@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/aHXNDWm8601N589OgGjnj3wNd_4
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change @12
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 23:20:41 -0000

> On Dec 10, 2014, at 6:41 AM, Steve Donovan  =
wrote:
>=20
> Ulrich,
>=20
> This paragraph is talking about capability announcement.  We deal with =
the issues related to multiple sources of overload reports already =
elsewhere in the document.
>=20
> I still do see the need for a change.

Those sentences seem contradictory, at least in town. Did you mean to =
say you do _not_ see the need for a change?

>=20
> Steve
>=20
> On 12/9/14, 10:46 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Steve,
>> I agree, my comment and proposal do not hit the mark.
>> =20
>> The intention was to say that known issues exist if there are =
multiple agents on multiple paths between client and server. The agents =
may not be able to ensure that there is no ambiguity in DOIC behaviour =
for the client. E.g. from the client=92s point of view the answer to a =
first request (which was modified by agent A1) could indicate: DOIC is =
supported, currenty no overload, once in overload loss will be selected; =
and the answer to the next request (which was modified by agent A2) =
could indicate: DOIC is supported, some?? reduction is requested using =
rate. The client, however, may not be prepared for rate.
>> =20
>> Maybe a warning note could be added to say that the agent may not =
always be able to ensure that there is no ambiguity.
>> =20
>> Ulrich
>> =20
>> =20
>> =20
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve =
Donovan
>> Sent: Tuesday, December 09, 2014 2:45 PM
>> To: dime@ietf.org
>> Subject: [Dime] Ulrich's suggested change @12
>> =20
>> Ulrich,
>>=20
>> For your suggested change #12:
>>=20
>> Section 4.1.3, last paragraph:
>> Existing text:
>>    When making changes to the OC-Supported-Features AVP the Diameter
>>    Agent needs to ensure that there is no ambiguity in DOIC behavior =
for
>>    both upstream and downstream DOIC nodes.
>> =20
>> Comment: while that is true, in addition problems similar to those=20
>> identified in the note in section 3.3 may result from making changes.
>> =20
>> Proposal: Add the note:
>>       Note: Known issues exist if multiple sources for overload =
reports
>>       which apply to the same Diameter entity exist.  Reacting nodes
>>       have no way of determining the source and, as such, will treat
>>       them as coming from a single source.  Variance in sequence =
numbers
>>       between the two sources can then cause incorrect overload
>>       abatement treatment to be applied for indeterminate periods of
>>       time.
>> I don't understand how these are related.  The change to the =
OC-Supported-Features AVP made by the agent apply only to the =
transaction.  In addition, this paragraph doesn't mention overload =
reports.
>>=20
>> Regards,
>>=20
>> Steve
>>=20
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Dec 10 15:26:17 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1825D1AC429 for ; Wed, 10 Dec 2014 15:26:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWnck0YdTE9x for ; Wed, 10 Dec 2014 15:26:12 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB751AC423 for ; Wed, 10 Dec 2014 15:26:12 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBANQBlB012457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 17:26:12 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <54884137.4050209@usdonovans.com>
Date: Wed, 10 Dec 2014 17:26:11 -0600
X-Mao-Original-Outgoing-Id: 439946771.388686-06111d28fca061cf35f0cfca154f6fe1
Content-Transfer-Encoding: quoted-printable
Message-Id: <5AB8BAC5-3CBD-432E-9631-74DF40795844@nostrum.com>
References: <5486FE71.70205@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235215@DEMUMBX014.nsn-intra.net> <54884137.4050209@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/4ikF2SauDODcqiE1fO3PaYuMxas
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #15
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 23:26:15 -0000

>=20
> On Dec 10, 2014, at 6:48 AM, Steve Donovan  =
wrote:
>=20
> Ulrich,
>=20
> Actually, the wording you suggested wasn't quite right.  It should be:
>=20
>   When receiving an OC-OLR AVP with unknown values, the overload =
report
>   SHOULD be silently discarded by reacting nodes and the event SHOULD
>   be logged.
>=20
> It's not just about report type values but unknown values for any of =
the AVPs in the OLR.
>=20
> This seems like a good requirement to include in the specification to =
ensure common behavior in reacting nodes.  I don't feel strongly about =
this but I would like to hear other opinions.

I think this is still not quite complete.

If you receive a sub-AVP that you don't understand, then you should =
ignore that sub-avp, not the whole OC-OLR AVP.  (Unless of course the =
unknown AVP has the m-bit set.) If you receive a known sub-AVP, with a =
value you don't understand, the behavior should be AVP specific. For =
Report-Type, that means ignore the whole OLR.

It's not clear to me whether the original text was about arbitrary avps, =
or Report-Type.

>=20
> Steve
>=20
> On 12/9/14, 11:04 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Hi Steve,
>>=20
>> I think it was pointed out by Ben that we do not specify behaviour of =
a node for cases where it detects that another node is breaking the =
rule.
>> The rule is:
>>    A reporting node MUST NOT send overload reports of a type that has
>>    not been advertised as supported by the reacting node.
>> See section 4.2.3.
>>=20
>> Regards
>> Ulrich
>>=20
>>  =20
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve =
Donovan
>> Sent: Tuesday, December 09, 2014 2:52 PM
>> To: dime@ietf.org
>> Subject: [Dime] Ulrich's suggested change #15
>>=20
>> Ulrich,
>>=20
>> For your suggested change #15:
>> Section 4.2.1.3, 4th paragraph:
>> Existing text:
>>    When receiving an OC-OLR AVPs with unknown values, a reacting node
>>    SHOULD be silently discarded by reacting nodes and the event =
SHOULD
>>    be logged.
>> Comment: text is confusing. Maybe the intention was to say:
>>    When receiving an OC-OLR AVPs with an unsupported report type =
value, a reacting node
>>    SHOULD silently discarded the OC-OLR AVP and the event SHOULD
>>    be logged.
>> But even that is not correct.
>> Proposal: Remove the paragraph.
>> The intent was that an OC-OLR that contains unknown values should be =
discarded.  I agree that the wording needs to be changes as you =
suggested.  I don't agree with removing the paragraph.  Can you =
elaborate on why you think it is not correct when changed as you =
suggested?
>>=20
>> Regards,
>>=20
>> Steve
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Dec 10 15:43:01 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 298CF1A6FCC for ; Wed, 10 Dec 2014 15:43:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SyQ6g-J3tTG for ; Wed, 10 Dec 2014 15:42:58 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0C41AC41A for ; Wed, 10 Dec 2014 15:42:58 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBANgvqp013854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 17:42:57 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <548701E1.3060502@usdonovans.com>
Date: Wed, 10 Dec 2014 17:42:56 -0600
X-Mao-Original-Outgoing-Id: 439947776.847133-1386f3fc4ec59ac378a6f4af09e223dc
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A70A6FF-1A7B-4372-BD05-B96C7DE69F9F@nostrum.com>
References: <548701E1.3060502@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iTCLCWw-ZNN5OFMreH3TNYfqJgA
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #16
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 23:43:00 -0000

> On Dec 9, 2014, at 8:06 AM, Steve Donovan  =
wrote:
>=20
> Ulrich,
>=20
> For your suggested change #16:
>=20
> Section 4.2.2, 5th and 6th paragraph:
> Existing text:
>    If the request is a host-routed request then the reacting node =
SHOULD
>    apply throttling abatement treatment to the request.
> =20
>    If the request is a realm-routed request then the reacting node
>    SHOULD apply diversion abatement treatment to the request.
>=20
> Comment: I don't think so. If the reacting node selects the server and=20=

> then detects that the selected server is overloaded and then detects =
that=20
> the request does not survive (i.e. is subject to abatement), then the =
reacting=20
> node SHOULD apply diversion treatment (i.e. select an alternative =
server if possible).=20
> If the reacting node does not select the server (either a. because the =
server was=20
> already selected by a downstream node, or b. because the server will =
be selected=20
> by an upstream node) then there is no point in applying diversion and =
the reacting=20
> node SHOULD apply throttling of requests that do not survive.
>=20
> Proposal: replace the paragraphs with:
>    If the reacting node does not select the server then it SHOULD =
apply
>    throttling abatement to the request.
>=20
>    If the reacting node selects the server then it SHOULD apply =
diversion
>    abatement treatment (i.e. select an alternative server if possible) =
to
>    the request.
>=20
> Diversion is not selecting an alternative node to handle the request.  =
Diversion is selecting an alternative route to the selected node.

Hmm. Isn't that only true for the proposed Peer-Report type in the Agent =
draft?

> =20
>=20
> Whether it is appropriate to select an alternative node for a request =
is an application decision that probably changes on a per command-code =
basis within the application.  Logic like this is outside the scope of =
the DOIC specification.

So how does it work for existing applications? But I agree in principle. =
I somehow missed that we had 2119 language around this. I think the =
choice to apply diversion vs throttling should be local policy. We don't =
need to state it normatively.

>=20
> The text is correct based on the definition of diversion.

I'm not sure we have that definition right.

>=20
> Regards,
>=20
> Steve
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Dec 10 15:46:34 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0FF1A8893 for ; Wed, 10 Dec 2014 15:46:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kviUC1mURAn for ; Wed, 10 Dec 2014 15:46:30 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EA3D1A0105 for ; Wed, 10 Dec 2014 15:46:30 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBANkLkk014188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 17:46:22 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <087A34937E64E74E848732CFF8354B920987F790@ESESSMB101.ericsson.se>
Date: Wed, 10 Dec 2014 17:46:20 -0600
X-Mao-Original-Outgoing-Id: 439947980.746668-a78412d98b2ed0e7d07df1b550061c6b
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <545792B6.8030502@usdonovans.com> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, > <087A34937E64E74E848732CFF8354B9209863A54@ESESSMB101.ericsson.se> <24987_1416213505_5469B401_24987_4151_1_judb1lo2cnj5m4v6mdt5aec1.1416213483721@email.android.com>  <54748CEA.3020705@usdonovans.com> <19072_1416939968_5474C9C0_19072_1519_1_6B7134B31289DC4FAF731D844122B36E941639@PEXCVZYM13.corporate.adroot.infra.ftgroup> <547E09C0.5080305@usdonovans.com>   <547F46D5.7060800@usdonovans.! com> <087A34937E64E74E848732CFF8354B920987F790@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/0QraW2gZBLTXvLGnugZAeGQtdds
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Updates to DOIC -05
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 23:46:33 -0000

> On Dec 10, 2014, at 9:09 AM, Maria Cruz Bartolome =
 wrote:
>=20
> Dear all,
> =20
> I have the following proposal, for first paragraph
> Now:
> Therefore, before
>    applying local message throttling, a reporting node needs to check =
if
>    these messages match existing OCS entries,
> =20
> Proposal
> Therefore, before
>    applying local message throttling, a reporting node MAY check if
>    these messages match existing OCS entries,
> =20
> I think the reporting node may or not check whether the received =
messages match a =93delegated=94 active OCS. This is a processing =
consuming task that could be avoided if the reporting node uses =
different criteria to choose messages to drop/reject. This is up to  =
implementation.

I am okay with it being up to the implementation. I think the point of =
the warning is to let implementers know they need to consider this.=20

But I wonder why you want to add 2119 language when it didn't have it =
before?


> =20
> Best regards
> /MCruz
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
> Sent: mi=E9rcoles, 03 de diciembre de 2014 18:22
> To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); lionel.morand@orange.com; =
Ben Campbell
> Cc: dime@ietf.org
> Subject: Re: [Dime] Updates to DOIC -05
> =20
> I have attempted to address both Lionel's and Jean-Jacques' =
suggestions with the following text:
>=20
>    When a reporting node sends an OLR, it effectively delegates any
>    necessary throttling to downstream nodes.  If the reporting node =
also
>    locally throttles the same set of messages, the overall number of
>    throttled requests may be higher than intended.  Therefore, before
>    applying local message throttling, a reporting node needs to check =
if
>    these messages match existing OCS entries, indicating that these
>    messages have survived throttling applied by downstream nodes that
>    have received the related OLR.
> =20
>    However, even if the set of messages match existing OCS entries, =
the
>    reporting node can still apply other abatement methods such as
>    diversion.  The reporting node might also need to throttle requests
>    for reasons other than overload.  For example, an agent or server
>    might have a configured rate limit for each client, and throttle
>    requests that exceed that limit, even if such requests had already
>    been candidates for throttling by downstream nodes.  The reporting
>    node also has the option to send new OLRs requesting greater
>    reductions in traffic, reducing the need for local throttling.
>=20
> Steve
>=20
> On 12/3/14, 6:19 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> Dear all
> =20
> To continue on my remark , I would complement the Steve=92s text with =
=93 can update the reduction of traffic it requires from the reacting =
nodes(s) by sending new overload reports=94 as hereafter:   =20
> =20
>    Therefore, if a
>    reporting node needs to apply local throttling on a set of messages
>    that match existing OCS entries, it needs to consider
>    the impact of throttling by downstream nodes and can update the =
reduction of traffic it requires from the reacting nodes(s) by sending =
new overload reports.=20
> =20
> Best regards
> =20
> JJacques
> =20
> =20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, =
JEAN-JACQUES (JEAN-JACQUES)
> Envoy=E9 : mercredi 3 d=E9cembre 2014 11:29
> =C0 : Steve Donovan; lionel.morand@orange.com; Ben Campbell
> Cc : dime@ietf.org
> Objet : Re: [Dime] Updates to DOIC -05
> =20
> Dear all
> =20
> I am not against the new proposed texts from Steve or Ben to clarify =
this topic.
> =20
> My point is that, when  the reporting node has sent an OLR requiring  =
a traffic reduction , there is first a reaction time before receiving =
reduced traffic, and second even if the traffic has been reduced, it can =
still exceed the capacity of the reporting node  that has no other =
choice than to throttle the received reduced traffic (if no diversion). =
This can happen when the traffic at the source (reacting node) before =
throttling is increasing quickly, so the traffic reduced  according to =
the received OLR may  remain too high .  Then, if the reporting node has =
nevertheless to do some throttle, it will certainly react by new OLRs =
requiring a higher traffic reduction from the reacting nodes. This is a =
dynamic process, where the reporting node adjust the  traffic  reduction =
it requires according to what it receives .
> =20
> As Ben  I also think this is a guidance , and I think it is good to =
bring some guidance.
> =20
> Best regards
> =20
> JJacques
> =20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
> Envoy=E9 : mardi 2 d=E9cembre 2014 19:50
> =C0 : lionel.morand@orange.com; Ben Campbell
> Cc : dime@ietf.org
> Objet : Re: [Dime] Updates to DOIC -05
> =20
> Lionel,
>=20
> The two paragraphs together now say the following:
>=20
>    When a reporting node sends an OLR, it effectively delegates any
>    necessary throttling to downstream nodes.  If the reporting node =
also
>    locally throttles the same set of messages, the overall number of
>    throttled request may be higher than intended.  Therefore, if a
>    reporting node needs to apply local throttling on a set of messages
>    that match or overlap with existing OCS entries, it needs to =
consider
>    the impact of throttling by downstream nodes.
> =20
>    However, when the reporting node sends an OLR downstream, it might
>    still need to apply other abatement methods such as diversion.  The
>    reporting node might also need to throttle requests for reasons =
other
>    than overload.  For example, an agent or server might have a
>    configured rate limit for each client, and throttle requests that
>    exceed that limit, even if such requests had already been =
candidates
>    for throttling by downstream nodes.
> Do you see the need for further clarification?
>=20
> Steve
>=20
> On 11/25/14, 12:26 PM, lionel.morand@orange.com wrote:
> I'm OK with the idea of the text proposed by Ben.
> I would just make clear that throttling is applicable to the fact of =
sending/forwarding requests (cf. definition). A reporting node may apply =
local throttling if it is an agent. But if it is a server, it can either =
drop the exceeded number of requests (no response sent to the =
downstream) or send a specific DIAMETER-TOO-BUSY response. I think that =
this clarification is somehow missing in the document.
> =20
> Regards,
> =20
> Lionel
> =20
> -----Message d'origine-----
> De : Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> Envoy=E9 : mardi 25 novembre 2014 15:07
> =C0 : Ben Campbell; MORAND Lionel IMT/OLN
> Cc : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; Maria Cruz =
Bartolome
> Objet : Re: [Dime] Updates to DOIC -05
> =20
> I'm ok with Ben's wording and will make the change unless I hear =
objections on the list.
> =20
> Steve
> =20
> On 11/21/14, 5:01 PM, Ben Campbell wrote:
> On reflection, I think there might be a subtlety here. The resulting =
offered-load may still exceed the reporting node's current capacity. =
This can be true even if it's sent an OLR (and thus has related OCS). As =
mentioned in the surrounding node needs to still be able to protect =
itself, possibly by throttling. Therefore, I propose the sentence take =
the form of non-normative guidance. For example:
> =20
> "When a reporting node sends an OLR, it effectively delegates any =
necessary throttling to downstream nodes.  If the reporting node also =
locally throttles the same set of messages, the overall number of =
throttled request may be higher than intended. Therefore, if a reporting =
node needs to apply local throttling on a set of messages that match or =
overlap with existing OCS entries, it needs to consider the impact of =
throttling by downstream nodes."
> =20
>  =20
> On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com wrote:
> =20
> I can live with the text proposed by Ulrich. But what is wrong with:
> =20
> " Therefore, the reporting node SHOULD NOT apply throttling to the set =
of messages to which an active OCS applies." ?
> =20
> Envoy=E9 depuis mon Sony Xperia SP d'Orange
> =20
> ---- Maria Cruz Bartolome a =E9crit ----
> =20
> =20
> Section 4.2.3, 13th paragraph, 2nd sentence:
> Existing text: Therefore, the reporting node SHOULD NOT apply =
throttling to the set of messages to which the OLR applies.
> Proposed text: Therefore, the reporting node SHOULD NOT apply =
throttling to the set of messages to which the sent OLR applies.
> =20
> [LM] I would say that the reporting node will not remember the =
previously sent OLR, but will take care that there is an active OCS.
> SRD> I'm ok with Ulrich's change.
> =20
> [LM] and this is incorrect but not fundamental. The reporting node =
does not have to "remember" a previously sent OLR. What it will do is to =
refer to existing OCS to know that throttling should not be applied. An =
OCS is a consequence of an sent OLR but it is not an OLR itself. But not =
fundamental here.
> =20
> [MCruz] I am ok with Ulrich's change. It does not mean that the =
reporting node needs to "remember" a previously sent OLR, though. The =
change only proposes to "identify" which OLR we refer to.
> =20
> Best regards
> /MCruz
> =20
> =20
> _____________________________________________________________________
> ____________________________________________________
> =20
> Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20=

> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> 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.
> =20
> This message and its attachments may contain confidential or=20
> 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.
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =20
> =20
> =
__________________________________________________________________________=
_______________________________________________
> =20
> 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.
> =20
> 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.
> =20
> =20
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Dec 10 15:50:31 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5ECF1A1B15 for ; Wed, 10 Dec 2014 15:50:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piHH5pS4eRDs for ; Wed, 10 Dec 2014 15:50:28 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1B51A1A4D for ; Wed, 10 Dec 2014 15:50:28 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBANoRi3014486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 17:50:27 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <54883CBA.7060503@usdonovans.com>
Date: Wed, 10 Dec 2014 17:50:26 -0600
X-Mao-Original-Outgoing-Id: 439948226.837631-9906c435ce13a3d7ef44a08acb0101e6
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <54862C38.1000403@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152350CF@DEMUMBX014.nsn-intra.net> <54883CBA.7060503@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/sxqEZMo_EhgUxcPwDpIxJz37SAs
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich suggested change number 1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Dec 2014 23:50:30 -0000

> On Dec 10, 2014, at 6:29 AM, Steve Donovan  =
wrote:
>=20
> Ulrich,
>=20
> I think I see the source of confusion.  It is meant to talk about =
sending to adjacent DOIC nodes but it uses the words reacting and =
reporting nodes.  I suggest changing the paragraph to the following, =
removing the concept of reporting and reacting nodes from the =
description.
>=20
>   While a DOIC node sends OLRs to "adjacent" DOIC nodes, nodes
>   that are "adjacent" for DOIC purposes may not be adjacent from a
>   Diameter, or transport, perspective.  For example, one or more
>   Diameter agents that do not support DOIC may exist between a given
>   pair of DOIC nodes, as long as those agents pass
>   unknown AVPs through unchanged.  The report types described in this
>   document can safely pass through non-supporting agents.  This may =
not
>   be true for report types defined in future specifications.
>=20

I like this approach.

I also note that, for a given transaction, the black-box behavior of a =
supporting-agent that passes OC AVPs unchanged id identical to that of =
an a non-supporting agent.


> Regards,
>=20



> Steve
>=20
> On 12/9/14, 7:16 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Steve,
>>=20
>> please see inline.
>>=20
>> Ulrich
>>=20
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve =
Donovan
>> Sent: Monday, December 08, 2014 11:55 PM
>> To: dime@ietf.org
>> Subject: [Dime] Ulrich suggested change number 1
>>=20
>> Ulrich,
>>=20
>> I'll deal with each of your suggestion in a separate email to help =
ensure that nothing is missed.
>>=20
>> For your first suggestion:
>> Section 3, last paragraph:
>> Existing text:
>>    While a reporting node sends OLRs to "adjacent" reacting nodes, =
nodes
>>    that are "adjacent" for DOIC purposes may not be adjacent from a
>>    Diameter, or transport, perspective.  For example, one or more
>>    Diameter agents that do not support DOIC may exist between a given
>>    pair of reporting and reacting nodes, as long as those agents pass
>>    unknown AVPs through unchanged.  The report types described in =
this
>>    document can safely pass through non-supporting agents.  This may =
not
>>    be true for report types defined in future specifications.
>>=20
>> Comment: while this is all not wrong, the existing text may convey =
the erring
>> impression that there cannot be a DOIC supporting agent on the path =
between a
>> reporting node and an adjacent reacting node.
>>=20
>> Proposal: It is proposed to add the following sentence at the end of =
the paragraph:
>>    Another example is where one or more Diameter agents that do =
support
>>    DOIC may exist between a given pair of reporting and reacting =
nodes,
>>    as long as those agents pass OC-specific AVPs through unchanged.
>> I don't agree with the suggested change, as the DOIC supporting =
agents might need to change the OC-specific AVPs.
>>  I agree that in some cases DOIC supporting agents need to =
change the OC-specific AVPs. However, there are also cases where DOIC =
supporting agents do not need to change OC-specific AVPs.
>>   I also don't understand how the paragraph implies that there cannot =
be DOIC supporting agents in the path of the request.
>>  It does not imply that. Rather it may convey the erring =
impression that there cannot be a DOIC supporting agent on the path =
between a
>> reporting node and an adjacent reacting node.
>>    It is talking specifically about the case where there agents do =
not support DOIC are in the path.
>>  No, my understanding is that the paragraph is talking =
specifically about what "adjacent for DOIC purposes" means. One valid =
example is given (reporting node and reacting node are "adjacent for =
DOIC purposes" if one or more agents that do not support DOIC but pass =
unsupported AVPs through unchanged exist between reporting node and =
reacting node) and I do not propose to remove that. However, there is =
another important valid example (reporting node and reacting node are =
"adjacent for DOIC purposes" if one or more DOIC supporting agents that =
pass OC-specific AVPs through unchanged exist between reporting node and =
reacting node), and the proposal is to add text to cover this example. =

>> The remainder of the document makes it clear that there can be agents =
that do support DOIC in the path of a transaction.
>>  that is not my point. The point is to clearly state that =
there can be DOIC supporting agents that pass through OC-specific AVPs =
unchanged on the path between reporting node and reacting node, and in =
this case the reporting and reacting nodes are still regarded "adjacent =
for DOIC purposes".
>>=20
>> I don't see the need for a change here.
>>  I'm not proposing a modification but an addition. This =
addition provides useful clarification and in no way is harmful
>>=20
>> Regards,
>>=20
>> Steve
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Dec 10 16:08:43 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0999C1ACCFF for ; Wed, 10 Dec 2014 16:08:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44WHds3PUMf5 for ; Wed, 10 Dec 2014 16:08:34 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C951ACCF3 for ; Wed, 10 Dec 2014 16:08:34 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBB08T7l016004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 18:08:29 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <087A34937E64E74E848732CFF8354B920987F783@ESESSMB101.ericsson.se>
Date: Wed, 10 Dec 2014 18:08:28 -0600
X-Mao-Original-Outgoing-Id: 439949308.66784-9b50e8340da5c00e315e097b4add93a9
Content-Transfer-Encoding: quoted-printable
Message-Id: <767BF9E5-A72B-44B5-A324-A0CF74F70A69@nostrum.com>
References: <46C8B155-A8B0-41F6-A8A5-6F21D61ADE9E@nostrum.com> <087A34937E64E74E848732CFF8354B920987F783@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5S_cHheZPQNoHM9jOPQBiAV7vd8
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Updated DOIC Requirements Analysis
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 00:08:38 -0000

> On Dec 10, 2014, at 9:09 AM, Maria Cruz Bartolome =
 wrote:
>=20
> Hello,
> =20
> See some comments below
> Thanks
> /MCruz
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
> Sent: martes, 25 de noviembre de 2014 3:19
> To: dime@ietf.org list
> Subject: [Dime] Updated DOIC Requirements Analysis

[...]

> =20
> C.2.  Detection of non-supporting Intermediaries
> =20
>    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.
> =20
>    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.
> =20

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

[...]

> =20
> =20
> =20
>    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.
> =20
>            *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.
> =20
> [MCruz] Could you clarify last example? =E2=80=9Cwithoug =
configuration=E2=80=9D? 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.

=46rom 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.

[...]


> =20
>    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.
> =20
>            *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.
> =20
> [MCruz] Partly Compliant. DOIC Overload information can be used =
already by proprietary load-balancing implementations.
>=20
> Load information will be a plus to this.
>=20

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.

[...]

> =20
> =20
>    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.
> =20
>            *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?

9.3

/Ben.


From nobody Wed Dec 10 16:16:48 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C353C1ACD12 for ; Wed, 10 Dec 2014 16:16:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqq1hk14Gwcr for ; Wed, 10 Dec 2014 16:16:39 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EBF31ACD13 for ; Wed, 10 Dec 2014 16:16:39 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBB0GZha016614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 18:16:36 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <087A34937E64E74E848732CFF8354B920987F7B8@ESESSMB101.ericsson.se>
Date: Wed, 10 Dec 2014 18:16:35 -0600
X-Mao-Original-Outgoing-Id: 439949795.324448-c64d21a5739dbbe7cfd784648939c154
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D865883-A81C-429D-9829-8A23761DC903@nostrum.com>
References: <5486EFAA.7090902@usdonovans.com> <087A34937E64E74E848732CFF8354B920987F7B8@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/wyJT7Z0S0mjf3UP5ITi-jJa8eVM
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich suggested change number 4
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 00:16:45 -0000

I am okay with either the old or the proposed text. I can construct a =
style argument that favors each :-)

> On Dec 10, 2014, at 9:09 AM, Maria Cruz Bartolome =
 wrote:
>=20
> I agree
> /MCruz
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
> Sent: martes, 09 de diciembre de 2014 13:49
> To: dime@ietf.org
> Subject: [Dime] Ulrich suggested change number 4
> =20
> Ulrich,
>=20
> For your fourth suggested change:
>=20
> Section 3.3, 4th and 5th paragraph:
> Existing text:
>    A report of type "HOST_REPORT" is sent to indicate the overload of =
a
>    specific Diameter node for the application-id indicated in the
>    transaction.  When receiving an OLR of type host, a reacting node
>    applies overload abatement to what is referred to in this document =
as
>    host-routed requests.  The reacting node applies overload abatement
>    on those host-routed requests which the reacting node knows will be
>    served by the server that matches the Origin-Host AVP of the =
received
>    message that contained the received OLR of type host.
> =20
>    A report of type "REALM_REPORT" applies to realm-routed requests =
for
>    a specific realm as indicated in the Destination-Realm AVP.
> Comment: While the 4th paragraph is all fine, the 5th paragraph should =
be aligned.
> Proposal: It is proposed to replace the 5th paragraph with:
>    A report of type "REALM_REPORT" is sent to indicate the overload of =
all
>    Diameter nodes within a realm for the application-id indicated in =
the
>    transaction.  When receiving an OLR of type realm, a reacting node
>    applies overload abatement to what is referred to in this document =
as
>    realm-routed requests.  The reacting node applies overload =
abatement
>    on those realm-routed requests which contain  a Destination-Realm =
AVP
>    that matches the Origin-Realm AVP of the received message that
>    contained the received OLR of type realm.
> I support the suggested change.
>=20
> Regards,
>=20
> Steve
>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Dec 10 16:21:20 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867611ACD16 for ; Wed, 10 Dec 2014 16:21:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5QQ2Xckk8Hg for ; Wed, 10 Dec 2014 16:21:12 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB8E1A1A2D for ; Wed, 10 Dec 2014 16:21:12 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBB0L8R4016930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 18:21:09 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <087A34937E64E74E848732CFF8354B920987F7D0@ESESSMB101.ericsson.se>
Date: Wed, 10 Dec 2014 18:21:08 -0600
X-Mao-Original-Outgoing-Id: 439950068.326793-af41c7e3c3a90be9b6e4b709296cfaa0
Content-Transfer-Encoding: quoted-printable
Message-Id: <509E2BC4-23E2-4966-83DD-95A479766D41@nostrum.com>
References: <5486FBA8.9020206@usdonovans.com> <087A34937E64E74E848732CFF8354B920987F7D0@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/wiK3SfjQm0G6FLuopHu3QV64FXU
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #11
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 00:21:17 -0000

Agreed. "MUST only" is actually one of my pet peeves for 2119 language =
abuse. I'm mortified to have missed that one :-)


> On Dec 10, 2014, at 9:09 AM, Maria Cruz Bartolome =
 wrote:
>=20
> Fine
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
> Sent: martes, 09 de diciembre de 2014 14:40
> To: dime@ietf.org
> Subject: [Dime] Ulrich's suggested change #11
> =20
> Ulrich,
>=20
> For your  suggested change #11:
>=20
> Section 4.1.3, 6th paragraph:
> Existing text:
>    As with a Diameter endpoint taking on reporting node behavior, a
>    Diameter Agent MUST only include the OC-Supported-Features AVP in
>    answer messages for transactions where the request message received
>    by the Diameter Agent had an OC-Supported-Features AVP.
> Comments: "MUST only do x for condition y" could mean:
> a) "MUST do x for condition y and MUST NOT do x for conditions other =
than y", or
> b) "MUST do x and nothing else for condition y, and nothing is =
specified for conditions other than y".
> Proposal: Replace the paragraph with:
>    As with a Diameter endpoint taking on reporting node behavior, a
>    Diameter Agent MUST NOT include the OC-Supported-Features AVP in
>    answer messages for transactions where the request message received
>    by the Diameter Agent had no OC-Supported-Features AVP.
> I support this change.
>=20
> Regards,
>=20
> Steve
>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Thu Dec 11 00:32:14 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CE61A2119 for ; Thu, 11 Dec 2014 00:32:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTx0I-rBZAB5 for ; Thu, 11 Dec 2014 00:32:11 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF101A0110 for ; Thu, 11 Dec 2014 00:32:11 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBB8W7pd031767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Dec 2014 08:32:08 GMT
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBB8W3Lt030725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Dec 2014 09:32:06 +0100
Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 11 Dec 2014 09:32:03 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 09:32:03 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Ben Campbell , Steve Donovan 
Thread-Topic: [Dime] Ulrich's suggested change #15
Thread-Index: AQHQE7dJhQB5e1nbwEev114RSsJu35yHeSWggAE9+YCAALINgIAAn1BQ
Date: Thu, 11 Dec 2014 08:32:03 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815235522@DEMUMBX014.nsn-intra.net>
References: <5486FE71.70205@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235215@DEMUMBX014.nsn-intra.net> <54884137.4050209@usdonovans.com> <5AB8BAC5-3CBD-432E-9631-74DF40795844@nostrum.com>
In-Reply-To: <5AB8BAC5-3CBD-432E-9631-74DF40795844@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 3869
X-purgate-ID: 151667::1418286728-0000677A-7DE93ADA/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/O-pXPGQgyeEtYMnF3YV4Px91po4
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #15
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 08:32:14 -0000

Ben,
for my clarification:
you wrote: "If you receive a known sub-AVP, with a value you don't understa=
nd, the behavior should be AVP specific. For Report-Type, that means ignore=
 the whole OLR."

I would have thought that "For Report-Type, that means ignore the whole set=
 of OLRs".
At least it should be allowed to do that.

The requirement for the reporting node is to not send OLRs with report type=
 values that are unknown/unsupported by the reacting node.=20
The reporting node cannot assume that, when breaking this rule, the reactin=
g node will act in a predictable way. It should even be ok for the reportin=
g node to ignore the complete answer message.

Please let me know your comments.

Ulrich


-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com]=20
Sent: Thursday, December 11, 2014 12:26 AM
To: Steve Donovan
Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Ulrich's suggested change #15

>=20
> On Dec 10, 2014, at 6:48 AM, Steve Donovan  wro=
te:
>=20
> Ulrich,
>=20
> Actually, the wording you suggested wasn't quite right.  It should be:
>=20
>   When receiving an OC-OLR AVP with unknown values, the overload report
>   SHOULD be silently discarded by reacting nodes and the event SHOULD
>   be logged.
>=20
> It's not just about report type values but unknown values for any of the =
AVPs in the OLR.
>=20
> This seems like a good requirement to include in the specification to ens=
ure common behavior in reacting nodes.  I don't feel strongly about this bu=
t I would like to hear other opinions.

I think this is still not quite complete.

If you receive a sub-AVP that you don't understand, then you should ignore =
that sub-avp, not the whole OC-OLR AVP.  (Unless of course the unknown AVP =
has the m-bit set.) If you receive a known sub-AVP, with a value you don't =
understand, the behavior should be AVP specific. For Report-Type, that mean=
s ignore the whole OLR.

It's not clear to me whether the original text was about arbitrary avps, or=
 Report-Type.

>=20
> Steve
>=20
> On 12/9/14, 11:04 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Hi Steve,
>>=20
>> I think it was pointed out by Ben that we do not specify behaviour of a =
node for cases where it detects that another node is breaking the rule.
>> The rule is:
>>    A reporting node MUST NOT send overload reports of a type that has
>>    not been advertised as supported by the reacting node.
>> See section 4.2.3.
>>=20
>> Regards
>> Ulrich
>>=20
>>  =20
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>> Sent: Tuesday, December 09, 2014 2:52 PM
>> To: dime@ietf.org
>> Subject: [Dime] Ulrich's suggested change #15
>>=20
>> Ulrich,
>>=20
>> For your suggested change #15:
>> Section 4.2.1.3, 4th paragraph:
>> Existing text:
>>    When receiving an OC-OLR AVPs with unknown values, a reacting node
>>    SHOULD be silently discarded by reacting nodes and the event SHOULD
>>    be logged.
>> Comment: text is confusing. Maybe the intention was to say:
>>    When receiving an OC-OLR AVPs with an unsupported report type value, =
a reacting node
>>    SHOULD silently discarded the OC-OLR AVP and the event SHOULD
>>    be logged.
>> But even that is not correct.
>> Proposal: Remove the paragraph.
>> The intent was that an OC-OLR that contains unknown values should be dis=
carded.  I agree that the wording needs to be changes as you suggested.  I =
don't agree with removing the paragraph.  Can you elaborate on why you thin=
k it is not correct when changed as you suggested?
>>=20
>> Regards,
>>=20
>> Steve
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Thu Dec 11 01:55:22 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC901ACDB2 for ; Thu, 11 Dec 2014 01:55:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmonI9UE-c2N for ; Thu, 11 Dec 2014 01:55:16 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C14741ACDB0 for ; Thu, 11 Dec 2014 01:55:14 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBB9tCRe026964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Dec 2014 09:55:12 GMT
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBB9t9k8016932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Dec 2014 10:55:11 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 10:55:10 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Ben Campbell , Steve Donovan 
Thread-Topic: [Dime] Ulrich suggested change number 1
Thread-Index: AQHQEzn9APTOpOEpnEOsWl042ZAFN5yHKxAQgAGHrwCAAL4tAIAApwBQ
Date: Thu, 11 Dec 2014 09:55:10 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815235563@DEMUMBX014.nsn-intra.net>
References: <54862C38.1000403@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152350CF@DEMUMBX014.nsn-intra.net> <54883CBA.7060503@usdonovans.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 6853
X-purgate-ID: 151667::1418291713-0000658F-BFB3E100/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kuo7gWFLwBteAQiP4s-S1m5lVrQ
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich suggested change number 1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 09:55:19 -0000

Ben, Steve,

the confusion I think comes from the following:
1. the paragraph seems to try to define what "adjacent for DOIC purposes" m=
eans, but gives only one example and leaves it open whether other examples =
exist.
e.g.: Are two DOIC nodes adjacent for DOIC purposes when there is a DOIC su=
pporting agent (that passes OC-specific AVPs through unchanged) on the path=
 between them?
2. The paragraph says that OLRs are sent to nodes that are "adjacent for DO=
IC purpose". It's not clear whether the intention is to say=20
a) OLRs are sent to adjacent DOIC nodes rather than to adjacent Diameter no=
des, or
b) OLRs are sent to adjacent DOIC nodes rather than to non-adjacent DOIC no=
des.
And it's not clear whether OLRs are also sent to DOIC nodes that are not ad=
jacent for DOIC purposes.

In a configuration like this:

C-----A1------A2------S

where C, A1 and S support DOIC and A2 does not support DOIC but passes unkn=
own AVPs through unchanged we need to distinguish two cases:
1)  A1 passes OC-specific AVPs through unchanged
In this case C and S are adjacent for DOIC purposes, hence S sends OLRs to =
C.
2)  A1 modifies/replaces OC-specific AVPs
In this case C and A1 are adjacent for DOIC purpose and A1 and S are adjace=
nt for DOIC purpose, hence S ends OLRs to A1 and A1 sends OLRs to C.

Regards
Ulrich

=20

-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com]=20
Sent: Thursday, December 11, 2014 12:50 AM
To: Steve Donovan
Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Ulrich suggested change number 1


> On Dec 10, 2014, at 6:29 AM, Steve Donovan  wro=
te:
>=20
> Ulrich,
>=20
> I think I see the source of confusion.  It is meant to talk about sending=
 to adjacent DOIC nodes but it uses the words reacting and reporting nodes.=
  I suggest changing the paragraph to the following, removing the concept o=
f reporting and reacting nodes from the description.
>=20
>   While a DOIC node sends OLRs to "adjacent" DOIC nodes, nodes
>   that are "adjacent" for DOIC purposes may not be adjacent from a
>   Diameter, or transport, perspective.  For example, one or more
>   Diameter agents that do not support DOIC may exist between a given
>   pair of DOIC nodes, as long as those agents pass
>   unknown AVPs through unchanged.  The report types described in this
>   document can safely pass through non-supporting agents.  This may not
>   be true for report types defined in future specifications.
>=20

I like this approach.

I also note that, for a given transaction, the black-box behavior of a supp=
orting-agent that passes OC AVPs unchanged id identical to that of an a non=
-supporting agent.


> Regards,
>=20



> Steve
>=20
> On 12/9/14, 7:16 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Steve,
>>=20
>> please see inline.
>>=20
>> Ulrich
>>=20
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>> Sent: Monday, December 08, 2014 11:55 PM
>> To: dime@ietf.org
>> Subject: [Dime] Ulrich suggested change number 1
>>=20
>> Ulrich,
>>=20
>> I'll deal with each of your suggestion in a separate email to help ensur=
e that nothing is missed.
>>=20
>> For your first suggestion:
>> Section 3, last paragraph:
>> Existing text:
>>    While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
>>    that are "adjacent" for DOIC purposes may not be adjacent from a
>>    Diameter, or transport, perspective.  For example, one or more
>>    Diameter agents that do not support DOIC may exist between a given
>>    pair of reporting and reacting nodes, as long as those agents pass
>>    unknown AVPs through unchanged.  The report types described in this
>>    document can safely pass through non-supporting agents.  This may not
>>    be true for report types defined in future specifications.
>>=20
>> Comment: while this is all not wrong, the existing text may convey the e=
rring
>> impression that there cannot be a DOIC supporting agent on the path betw=
een a
>> reporting node and an adjacent reacting node.
>>=20
>> Proposal: It is proposed to add the following sentence at the end of the=
 paragraph:
>>    Another example is where one or more Diameter agents that do support
>>    DOIC may exist between a given pair of reporting and reacting nodes,
>>    as long as those agents pass OC-specific AVPs through unchanged.
>> I don't agree with the suggested change, as the DOIC supporting agents m=
ight need to change the OC-specific AVPs.
>>  I agree that in some cases DOIC supporting agents need to chang=
e the OC-specific AVPs. However, there are also cases where DOIC supporting=
 agents do not need to change OC-specific AVPs.
>>   I also don't understand how the paragraph implies that there cannot be=
 DOIC supporting agents in the path of the request.
>>  It does not imply that. Rather it may convey the erring impress=
ion that there cannot be a DOIC supporting agent on the path between a
>> reporting node and an adjacent reacting node.
>>    It is talking specifically about the case where there agents do not s=
upport DOIC are in the path.
>>  No, my understanding is that the paragraph is talking specifica=
lly about what "adjacent for DOIC purposes" means. One valid example is giv=
en (reporting node and reacting node are "adjacent for DOIC purposes" if on=
e or more agents that do not support DOIC but pass unsupported AVPs through=
 unchanged exist between reporting node and reacting node) and I do not pro=
pose to remove that. However, there is another important valid example (rep=
orting node and reacting node are "adjacent for DOIC purposes" if one or mo=
re DOIC supporting agents that pass OC-specific AVPs through unchanged exis=
t between reporting node and reacting node), and the proposal is to add tex=
t to cover this example. 
>> The remainder of the document makes it clear that there can be agents th=
at do support DOIC in the path of a transaction.
>>  that is not my point. The point is to clearly state that there =
can be DOIC supporting agents that pass through OC-specific AVPs unchanged =
on the path between reporting node and reacting node, and in this case the =
reporting and reacting nodes are still regarded "adjacent for DOIC purposes=
".
>>=20
>> I don't see the need for a change here.
>>  I'm not proposing a modification but an addition. This addition=
 provides useful clarification and in no way is harmful
>>=20
>> Regards,
>>=20
>> Steve
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Thu Dec 11 03:33:55 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0821A8788 for ; Thu, 11 Dec 2014 03:33:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5kK5ZBFjqpS for ; Thu, 11 Dec 2014 03:33:51 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FD3B1A1BEE for ; Thu, 11 Dec 2014 03:33:51 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBBBXnka016548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Dec 2014 11:33:49 GMT
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBBBXm9k005030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Dec 2014 12:33:49 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 11 Dec 2014 12:33:48 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 12:33:48 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Ben Campbell , Steve Donovan 
Thread-Topic: [Dime] Ulrich suggested changes 18, 19, 20 and 21
Thread-Index: AQHQFMWmX6ykzn5Ua0e5RAuJ+XtmdJyKQujA
Date: Thu, 11 Dec 2014 11:33:48 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668152355EE@DEMUMBX014.nsn-intra.net>
References: <5487050C.8080206@usdonovans.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1488
X-purgate-ID: 151667::1418297629-0000658F-285E2725/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/tlSLlW2N4yjy6VkSNxjMOwoW1DI
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich suggested changes 18, 19, 20 and 21
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 11:33:53 -0000

Ok for me to say just "or"
Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
Sent: Wednesday, December 10, 2014 11:07 PM
To: Steve Donovan
Cc: dime@ietf.org
Subject: Re: [Dime] Ulrich suggested changes 18, 19, 20 and 21


> On Dec 9, 2014, at 8:19 AM, Steve Donovan  wrot=
e:
>=20
> Ulrich,
>=20
> I support the suggested changes in your suggested changes 18, 19, 20 and =
21:
>=20
> Section 4.3, 3rd paragraph:
> Existing text:
>    The extension MAY define new AVPs for use in DOIC Capability
>    Announcement and for use in DOIC Overload reporting.  These new AVPs
>    SHOULD be defined to be extensions to the OC-Supported-Features and
>    OC-OLR AVPs defined in this document.
> Comment: It is not necessary for a new AVP to be an extension to both the=
 OC-Supported-Features AVP and the OC-OLR AVP.
> Proposal: Replace the paragraph with:
>    The extension MAY define new AVPs for use in DOIC Capability
>    Announcement and for use in DOIC Overload reporting.  These new AVPs
>    SHOULD be defined to be extensions to the OC-Supported-Features and/or
>    OC-OLR AVPs defined in this document.


"And/or" is an awkward construct. How about just "or"?  I think the context=
 makes it pretty clear that it's not "xor".

[...]

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Thu Dec 11 03:36:08 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1BF1ACDD2 for ; Thu, 11 Dec 2014 03:36:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bEU15Rzfp61 for ; Thu, 11 Dec 2014 03:36:06 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FE361ACD98 for ; Thu, 11 Dec 2014 03:36:05 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBBBa3wW022830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Dec 2014 11:36:04 GMT
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBBBa3lU009177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Dec 2014 12:36:03 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 11 Dec 2014 12:36:03 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 12:36:03 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Ben Campbell , Steve Donovan 
Thread-Topic: [Dime] Ulrich's suggest change number 6
Thread-Index: AQHQFMT4fdA9mts0YEGhUzVGlhazQJyKQ1lw
Date: Thu, 11 Dec 2014 11:36:03 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815235600@DEMUMBX014.nsn-intra.net>
References: <5486F0F1.8000200@usdonovans.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1360
X-purgate-ID: 151667::1418297764-0000658F-DE69068E/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Qjbpkbrq4Wj4G9Fiz25YvDzfyy0
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggest change number 6
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 11:36:07 -0000

The proposed simplification is ok for me.
Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
Sent: Wednesday, December 10, 2014 11:02 PM
To: Steve Donovan
Cc: dime@ietf.org
Subject: Re: [Dime] Ulrich's suggest change number 6


> On Dec 9, 2014, at 6:54 AM, Steve Donovan  wrot=
e:
>=20
> Ulrich,
>=20
> For your suggested change #6:
>=20
> Section 3.3, 12th paragraph:
> Existing text:
>    As the conditions that lead to the generation of the overload report
>    change the reporting node can send new overload reports requesting
>    greater reduction if the condition gets worse or less reduction if
>    the condition improves.  The reporting node sends an overload report
>    with a duration of zero to indicate that the overload condition has
>    ended and need for use of the abatement algorithm to reduce traffic
>    sent is no longer needed.
> Comment: Bad style.
> Proposal: Remove the words "need for" from the last sentence.
>=20
> I support the suggested change.

If we are going to change it, I propose a further simplification of the las=
t sentence:

"... and abatement is no longer needed."

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Thu Dec 11 04:40:55 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050651ACEC8 for ; Thu, 11 Dec 2014 04:40:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaN_vkPbnQbo for ; Thu, 11 Dec 2014 04:40:50 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8161E1ACECB for ; Thu, 11 Dec 2014 04:40:50 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBBCemGS019827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Dec 2014 12:40:48 GMT
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBBCejGH025753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Dec 2014 13:40:47 +0100
Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 11 Dec 2014 13:40:45 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 13:40:45 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Ulrich's suggested change #16
Thread-Index: AQHQE7lXyc+G3J0M1EW8kbPFxFEQNZyHfq1QgAE9VgCAAZrNMA==
Date: Thu, 11 Dec 2014 12:40:44 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681523562D@DEMUMBX014.nsn-intra.net>
References: <548701E1.3060502@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235234@DEMUMBX014.nsn-intra.net> <54884556.90108@usdonovans.com>
In-Reply-To: <54884556.90108@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681523562DDEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 15559
X-purgate-ID: 151667::1418301648-0000658F-B32F7F84/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/oaKQmxSpLLJgrO-BqjaQi2-u4ig
Subject: Re: [Dime] Ulrich's suggested change #16
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 12:40:54 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D90006681523562DDEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,
I find your new proposal more confusing.

I still think my original proposal is preferred. In addition the definition=
 for diversion may need to be updated.

Regards
Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, December 10, 2014 2:07 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Ulrich's suggested change #16

Ulrich,

I agree with your assumptions below.  For the third one, the only time it i=
s possible, at least from a DOIC perspective, to send to another host is if=
 it is a realm-routed request.  I might also change the "not overloaded" to=
 "less overloaded".

I do think the statements can be improved to differentiate between behavior=
 for host reports and realm reports.

How about the following:

   For OLRs of type host, if the request is a host-routed request then the =
reacting node SHOULD

   apply throttling abatement treatment to the request.



   For OLRs of type host, If the request is a realm-routed request then the=
 reacting node

   SHOULD apply diversion abatement treatment to the request.

   For OLRs of type realm, the reacting node SHOULD

   apply throttling abatement treatment to the request, independent of the =
type (host-routed or

   realm-routed) of request.


Regards,

Steve
On 12/9/14, 11:29 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Steve,

yes, then, maybe, the definition of Diversion is not correct?

What are other people's views?



My assumption was:

If a host is overloaded, it does not help to direct traffic to that host vi=
a a different path.

If a realm is overloaded, it does not help to direct traffic to that realm =
via a different path.

If a host is overloaded, it helps to select an alternative (not overloaded)=
 host (if possible) and direct traffic to that host.

If a realm is overloaded, there never is an alternative (not overloaded) re=
alm to which traffic could be directed.



With the current definition of Diversion, Diversion is no appropriate means=
 to address host overload and is no appropriate means to address realm over=
load. It may be ok for agent overload only.



Regards

Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan

Sent: Tuesday, December 09, 2014 3:06 PM

To: dime@ietf.org

Subject: [Dime] Ulrich's suggested change #16



Ulrich,



For your suggested change #16:

Section 4.2.2, 5th and 6th paragraph:

Existing text:

   If the request is a host-routed request then the reacting node SHOULD

   apply throttling abatement treatment to the request.



   If the request is a realm-routed request then the reacting node

   SHOULD apply diversion abatement treatment to the request.



Comment: I don't think so. If the reacting node selects the server and

then detects that the selected server is overloaded and then detects that

the request does not survive (i.e. is subject to abatement), then the react=
ing

node SHOULD apply diversion treatment (i.e. select an alternative server if=
 possible).

If the reacting node does not select the server (either a. because the serv=
er was

already selected by a downstream node, or b. because the server will be sel=
ected

by an upstream node) then there is no point in applying diversion and the r=
eacting

node SHOULD apply throttling of requests that do not survive.



Proposal: replace the paragraphs with:

   If the reacting node does not select the server then it SHOULD apply

   throttling abatement to the request.



   If the reacting node selects the server then it SHOULD apply diversion

   abatement treatment (i.e. select an alternative server if possible) to

   the request.

Diversion is not selecting an alternative node to handle the request.  Dive=
rsion is selecting an alternative route to the selected node.



Whether it is appropriate to select an alternative node for a request is an=
 application decision that probably changes on a per command-code basis wit=
hin the application.  Logic like this is outside the scope of the DOIC spec=
ification.



The text is correct based on the definition of diversion.



Regards,



Steve




--_000_5BCBA1FC2B7F0B4C9D935572D90006681523562DDEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,


I find you=
r new proposal more confusing.


 =
;


I still th=
ink my original proposal is preferred. In addition the definition for diver=
sion may need to be updated.


 =
;


Regards


Ulrich


 =
;






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Wednesday, December 10, 2014 2:07 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] Ulrich's suggested change #16<=
/p>





 


Ulrich,



I agree with your assumptions below.  For the third one, the only time=
 it is possible, at least from a DOIC perspective, to send to another host =
is if it is a realm-routed request.  I might also change the "not=
 overloaded" to "less overloaded".



I do think the statements can be improved to differentiate between behavior=
 for host reports and realm reports.



How about the following:


   For OLRs of type host, if the request is a host-routed re=
quest then the reacting node SHOULD


   apply throttling abatement treatment to the request.=



 


   For OLRs of type host, If the request is a realm-routed r=
equest then the reacting node


   SHOULD apply diversion abatement treatment to the request=
.


   For OLRs of type realm, the reacting node SHOULD


   apply throttling abatement treatment to the request, inde=
pendent of the type (host-routed or 


   realm-routed) of request.


 


Regards,



Steve




On 12/9/14, 11:29 AM, Wiehe, Ulrich (NSN - DE/Munich=
) wrote:






Steve,


yes, then, maybe, the definition of Diversion is not correct?


What are other people's views?


 


My assumption was:


If a host is overloaded, it does not help to direct traffic to that ho=
st via a different path.


If a realm is overloaded, it does not help to direct traffic to that r=
ealm via a different path.


If a host is overloaded, it helps to select an alternative (not overlo=
aded) host (if possible) and direct traffic to that host.


If a realm is overloaded, there never is an alternative (not overloade=
d) realm to which traffic could be directed.


 


With the current definition of Diversion, Diversion is no appropriate =
means to address host overload and is no appropriate means to address realm=
 overload. It may be ok for agent overload only.


 


Regards


Ulrich


 


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Steve Donovan


Sent: Tuesday, December 09, 2014 3:06 PM


To: dime@ietf.org

Subject: [Dime] Ulrich's suggested change #16


 


Ulrich,


 


For your suggested change #16:


Section 4.2.2, 5th and 6th paragraph:


Existing text:


   If the request is a host-routed request then the reacting=
 node SHOULD


   apply throttling abatement treatment to the request.=



 


   If the request is a realm-routed request then the re=
acting node


   SHOULD apply diversion abatement treatment to the request=
.


 


Comment: I don't think so. If the reacting node selects the server and=
 


then detects that the selected server is overloaded and then detects t=
hat 


the request does not survive (i.e. is subject to abatement), then the =
reacting 


node SHOULD apply diversion treatment (i.e. select an alternative serv=
er if possible). 


If the reacting node does not select the server (either a. because the=
 server was 


already selected by a downstream node, or b. because the server will b=
e selected 


by an upstream node) then there is no point in applying diversion and =
the reacting 


node SHOULD apply throttling of requests that do not survive.


 


Proposal: replace the paragraphs with:


   If the reacting node does not select the server then it S=
HOULD apply


   throttling abatement to the request.


 


   If the reacting node selects the server then it SHOULD ap=
ply diversion


   abatement treatment (i.e. select an alternative server if=
 possible) to


   the request.


Diversion is not selecting an alternative node to handle the request.&=
nbsp; Diversion is selecting an alternative route to the selected node.&nbs=
p; 


 


Whether it is appropriate to select an alternative node for a request =
is an application decision that probably changes on a per command-code basi=
s within the application.  Logic like this is outside the scope of the=
 DOIC specification.


 


The text is correct based on the definition of diversion.

 


Regards,


 


Steve


 




 






--_000_5BCBA1FC2B7F0B4C9D935572D90006681523562DDEMUMBX014nsnin_--


From nobody Thu Dec 11 05:17:09 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067421ACE47 for ; Thu, 11 Dec 2014 05:17:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5Zy43le0Epo for ; Thu, 11 Dec 2014 05:17:04 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E911A88B0 for ; Thu, 11 Dec 2014 05:17:03 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBBDH1qV000464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Dec 2014 13:17:01 GMT
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBBDGvNx017898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Dec 2014 14:17:00 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 14:17:00 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Ben Campbell 
Thread-Topic: [Dime] Ulrich's suggested change #8
Thread-Index: AQHQE7IIHC1/0vM3HEqfMpUtT/PrYZyHWeWwgAIHYACAAP1BQA==
Date: Thu, 11 Dec 2014 13:16:59 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815235657@DEMUMBX014.nsn-intra.net>
References: <5486F59E.4000908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235197@DEMUMBX014.nsn-intra.net> <57CA5812-ABE6-4974-8632-1BC40FA84082@nostrum.com>
In-Reply-To: <57CA5812-ABE6-4974-8632-1BC40FA84082@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 3660
X-purgate-ID: 151667::1418303821-0000677A-02A3F38C/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/arWUGEyaO5Q_z0oaaXmzJII9gNA
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #8
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 13:17:06 -0000

Ben,
would the following proposed text address your concern:

   A reporting node MUST NOT change the selected algorithm during the perio=
d
   of time that starts when entering an overload condition and ends when it
   is ensured that any non-expired reacting node's OCS entry created as a
   result of the overload condition in the reporting node is deleted.

In addition, is it so that outside that period the algorithm change can occ=
ur arbitrarily?
e.g. is it ok to change the algorithm in every second answer message while =
outside the period?
Or, is it ok to send rate while outside the period and send loss once the o=
verload condition is entered?
Note that section 3.2. says:

   Reacting nodes can use the indicated overload abatement algorithm to
   prepare for possible overload reports

Should we recommend not to change the algorithm too often while outside the=
 periode where change is prohibited?

Regards
Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com]=20
Sent: Wednesday, December 10, 2014 11:58 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Ulrich's suggested change #8


> On Dec 9, 2014, at 9:30 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:
>=20
> Steve,
>=20
> please see inline.
>=20
> Ulrich
>=20
>=20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
> Sent: Tuesday, December 09, 2014 2:14 PM
> To: dime@ietf.org
> Subject: [Dime] Ulrich's suggested change #8
>=20
> Ulrich,
>=20
> For your suggested change number 8:
> Section 4.1.2, 8th paragraph:
> Existing text:
>   For an ongoing overload condition, a reporting node MUST NOT change
>   the selected algorithm during the period of time that it is in an
>   overload condition and, as a result, is sending OC-OLR AVPs in answer
>   messages.
>=20
> Comment: As a result of an ongoing overload condition the reporting node =
is=20
> sending OC-OLR AVPs containing no validity duration or a validity duratio=
n=20
> different from zero in answer messages.
>=20
> Proposal: Replace the paragraph with:
>   For an ongoing overload condition, a reporting node MUST NOT change
>   the selected algorithm during the period of time that it is in an
>   overload condition and, as a result, is sending OC-OLR AVPs
>   containing no validity duration or a validity duration different
>   from zero in answer messages.
> I don't see the need for the change.  The selected algorithm should not c=
hange for all overload reports relating to an overload condition, including=
 overload reports with a validity duration of zero.
>  Isn't it so that when the overload condition ends (i.e. is no lo=
nger ongoing), the reporting node starts sending OLRs with validity duratio=
n of zero (for a long enough period of time)? (see end of section 4.2.1.4)=
=20
> The question now is whether the change of algorithm is allowed during thi=
s (long enough) period, or only after that period. I don't have a strong vi=
ew. But this was not my point.
> My point is that the current text seems to suggest that an overload condi=
tion is ongoing as long as OC-OLR AVPs are sent in answer messages, and I t=
hink that is not true. 
>=20

I think the proscription should last until the reporting node is (at least =
reasonably) sure that all reacting nodes have removed the OCS. The original=
 text comes closer to that than Ulrich's proposal, but I wonder if we shoul=
dn't cast this in similar terms as we do for the part about resending zero =
duration OLRs.


From nobody Thu Dec 11 05:31:09 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBCD1A1A20 for ; Thu, 11 Dec 2014 05:31:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ7C4geAWHBj for ; Thu, 11 Dec 2014 05:31:05 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E29A1A1B30 for ; Thu, 11 Dec 2014 05:31:05 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBBDV3Kw000739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Dec 2014 13:31:03 GMT
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBBDV33g014629 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Dec 2014 14:31:03 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 11 Dec 2014 14:31:02 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 14:31:02 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Ulrich's suggested change @12
Thread-Index: AQHQE7ZHD23zRsD0mUyK0fJgC7jhrJyHbHpAgAFIcACAAa52UA==
Date: Thu, 11 Dec 2014 13:31:01 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815235675@DEMUMBX014.nsn-intra.net>
References: <5486FCBF.4000707@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152351D9@DEMUMBX014.nsn-intra.net> <54883F5C.1060603@usdonovans.com>
In-Reply-To: <54883F5C.1060603@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.107]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D900066815235675DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 13771
X-purgate-ID: 151667::1418304663-0000677A-108D045E/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/NTudeHzoW_ukqcmoKGnOMW1vPeE
Subject: Re: [Dime] Ulrich's suggested change @12
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 13:31:08 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D900066815235675DEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,

yes, it's about capability announcement, and my concern in with announcing =
the selected algorithm in answer messages (while no OLRs are sent). Multipl=
e  agents modifying the selected algorithm in the Supported-Features AVPs i=
n answer messages may  result in ambiguity in DOIC behaviour for downstream=
 DOIC nodes.

Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, December 10, 2014 1:41 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Ulrich's suggested change @12

Ulrich,

This paragraph is talking about capability announcement.  We deal with the =
issues related to multiple sources of overload reports already elsewhere in=
 the document.

I still do see the need for a change.

Steve
On 12/9/14, 10:46 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Steve,

I agree, my comment and proposal do not hit the mark.



The intention was to say that known issues exist if there are multiple agen=
ts on multiple paths between client and server. The agents may not be able =
to ensure that there is no ambiguity in DOIC behaviour for the client. E.g.=
 from the client's point of view the answer to a first request (which was m=
odified by agent A1) could indicate: DOIC is supported, currenty no overloa=
d, once in overload loss will be selected; and the answer to the next reque=
st (which was modified by agent A2) could indicate: DOIC is supported, some=
?? reduction is requested using rate. The client, however, may not be prepa=
red for rate.



Maybe a warning note could be added to say that the agent may not always be=
 able to ensure that there is no ambiguity.



Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 09, 2014 2:45 PM
To: dime@ietf.org
Subject: [Dime] Ulrich's suggested change @12

Ulrich,

For your suggested change #12:

Section 4.1.3, last paragraph:

Existing text:

   When making changes to the OC-Supported-Features AVP the Diameter

   Agent needs to ensure that there is no ambiguity in DOIC behavior for

   both upstream and downstream DOIC nodes.



Comment: while that is true, in addition problems similar to those

identified in the note in section 3.3 may result from making changes.



Proposal: Add the note:

      Note: Known issues exist if multiple sources for overload reports

      which apply to the same Diameter entity exist.  Reacting nodes

      have no way of determining the source and, as such, will treat

      them as coming from a single source.  Variance in sequence numbers

      between the two sources can then cause incorrect overload

      abatement treatment to be applied for indeterminate periods of

      time.
I don't understand how these are related.  The change to the OC-Supported-F=
eatures AVP made by the agent apply only to the transaction.  In addition, =
this paragraph doesn't mention overload reports.

Regards,

Steve




--_000_5BCBA1FC2B7F0B4C9D935572D900066815235675DEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

yes, it=
217;s about capability announcement, and my concern in with announcing the =
selected algorithm in answer messages (while no OLRs are sent).
 Multiple  agents modifying the selected algorithm in the Supported-Fe=
atures AVPs in answer messages may  result in ambiguity in DOIC behavi=
our for downstream DOIC nodes.


 =
;


Ulrich


 =
;






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Wednesday, December 10, 2014 1:41 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] Ulrich's suggested change @12<=
/p>





 


Ulrich,



This paragraph is talking about capability announcement.  We deal with=
 the issues related to multiple sources of overload reports already elsewhe=
re in the document.



I still do see the need for a change.



Steve




On 12/9/14, 10:46 AM, Wiehe, Ulrich (NSN - DE/Munich=
) wrote:






Steve,


I agree, my comment and prop=
osal do not hit the mark.


 


The intention was to say tha=
t known issues exist if there are multiple agents on multiple paths between=
 client and server. The agents may not be able to ensure that there is no a=
mbiguity in DOIC behaviour for the client.
 E.g. from the client’s point of view the answer to a first request (=
which was modified by agent A1) could indicate: DOIC is supported, currenty=
 no overload, once in overload loss will be selected; and the answer to the=
 next request (which was modified by agent
 A2) could indicate: DOIC is supported, some?? reduction is requested using=
 rate. The client, however, may not be prepared for rate.=



 


Maybe a warning note could b=
e added to say that the agent may not always be able to ensure that there i=
s no ambiguity.


 


Ulrich


 


 


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Tuesday, December 09, 2014 2:45 PM

To: dime@ietf.org

Subject: [Dime] Ulrich's suggested change @12






 


Ulrich,



For your suggested change #12:


Section 4.1.3, last paragraph:


Existing text:


   When making changes to the OC-Supported-Features AVP the =
Diameter


   Agent needs to ensure that there is no ambiguity in DOIC =
behavior for


   both upstream and downstream DOIC nodes.


 


Comment: while that is true, in addition problems similar to those 


identified in the note in section 3.3 may result from making changes.<=
o:p>


 


Proposal: Add the note:


      Note: Known issues exist if multiple so=
urces for overload reports


      which apply to the same Diameter entity=
 exist.  Reacting nodes


      have no way of determining the source a=
nd, as such, will treat


      them as coming from a single source.&nb=
sp; Variance in sequence numbers


      between the two sources can then cause =
incorrect overload


      abatement treatment to be applied for i=
ndeterminate periods of


      time.


I don't understand ho=
w these are related.  The change to the OC-Supported-Features AVP made=
 by the agent apply only to the transaction.  In addition, this paragr=
aph doesn't mention overload reports.



Regards,



Steve










 






--_000_5BCBA1FC2B7F0B4C9D935572D900066815235675DEMUMBX014nsnin_--


From nobody Thu Dec 11 05:50:36 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0328C1ACE5D for ; Thu, 11 Dec 2014 05:50:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLP8BYVRRme6 for ; Thu, 11 Dec 2014 05:50:23 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372011ACE75 for ; Thu, 11 Dec 2014 05:50:23 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:58398 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Xz48G-0006C6-FA; Thu, 11 Dec 2014 05:50:21 -0800
Message-ID: <5489A118.10506@usdonovans.com>
Date: Thu, 11 Dec 2014 07:50:16 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  ext Ben Campbell 
References: <54862C38.1000403@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152350CF@DEMUMBX014.nsn-intra.net> <54883CBA.7060503@usdonovans.com>  <5BCBA1FC2B7F0B4C9D935572D900066815235563@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815235563@DEMUMBX014.nsn-intra.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/NC2wTbW9BOtP2FgeWkhM1cCT8dY
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich suggested change number 1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 13:50:25 -0000

Ulrich,

The paragraph is only trying to state that DOIC works through non 
supporting Diameter Agents, which is one of the requirements.

Furthermore, adjacent means "next to".  In your example, C and A1 are 
adjacent DOIC nodes and A1 and S are adjacent DOIC nodes.  C and S are 
never adjacent DOIC nodes because there is a DOIC node between them.

We could simplify the paragraph by saying "DOIC works through non 
supporting Diameter Agents that properly pass unknown AVPs unchanges."  
Maybe that would do away with the confusion about what adjacent means.

Steve


On 12/11/14, 3:55 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Ben, Steve,
>
> the confusion I think comes from the following:
> 1. the paragraph seems to try to define what "adjacent for DOIC purposes" means, but gives only one example and leaves it open whether other examples exist.
> e.g.: Are two DOIC nodes adjacent for DOIC purposes when there is a DOIC supporting agent (that passes OC-specific AVPs through unchanged) on the path between them?
> 2. The paragraph says that OLRs are sent to nodes that are "adjacent for DOIC purpose". It's not clear whether the intention is to say
> a) OLRs are sent to adjacent DOIC nodes rather than to adjacent Diameter nodes, or
> b) OLRs are sent to adjacent DOIC nodes rather than to non-adjacent DOIC nodes.
> And it's not clear whether OLRs are also sent to DOIC nodes that are not adjacent for DOIC purposes.
>
> In a configuration like this:
>
> C-----A1------A2------S
>
> where C, A1 and S support DOIC and A2 does not support DOIC but passes unknown AVPs through unchanged we need to distinguish two cases:
> 1)  A1 passes OC-specific AVPs through unchanged
> In this case C and S are adjacent for DOIC purposes, hence S sends OLRs to C.
> 2)  A1 modifies/replaces OC-specific AVPs
> In this case C and A1 are adjacent for DOIC purpose and A1 and S are adjacent for DOIC purpose, hence S ends OLRs to A1 and A1 sends OLRs to C.
>
> Regards
> Ulrich
>
>   
>
> -----Original Message-----
> From: ext Ben Campbell [mailto:ben@nostrum.com]
> Sent: Thursday, December 11, 2014 12:50 AM
> To: Steve Donovan
> Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] Ulrich suggested change number 1
>
>
>> On Dec 10, 2014, at 6:29 AM, Steve Donovan  wrote:
>>
>> Ulrich,
>>
>> I think I see the source of confusion.  It is meant to talk about sending to adjacent DOIC nodes but it uses the words reacting and reporting nodes.  I suggest changing the paragraph to the following, removing the concept of reporting and reacting nodes from the description.
>>
>>    While a DOIC node sends OLRs to "adjacent" DOIC nodes, nodes
>>    that are "adjacent" for DOIC purposes may not be adjacent from a
>>    Diameter, or transport, perspective.  For example, one or more
>>    Diameter agents that do not support DOIC may exist between a given
>>    pair of DOIC nodes, as long as those agents pass
>>    unknown AVPs through unchanged.  The report types described in this
>>    document can safely pass through non-supporting agents.  This may not
>>    be true for report types defined in future specifications.
>>
> I like this approach.
>
> I also note that, for a given transaction, the black-box behavior of a supporting-agent that passes OC AVPs unchanged id identical to that of an a non-supporting agent.
>
>
>> Regards,
>>
>
>
>> Steve
>>
>> On 12/9/14, 7:16 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>> Steve,
>>>
>>> please see inline.
>>>
>>> Ulrich
>>>
>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>>> Sent: Monday, December 08, 2014 11:55 PM
>>> To: dime@ietf.org
>>> Subject: [Dime] Ulrich suggested change number 1
>>>
>>> Ulrich,
>>>
>>> I'll deal with each of your suggestion in a separate email to help ensure that nothing is missed.
>>>
>>> For your first suggestion:
>>> Section 3, last paragraph:
>>> Existing text:
>>>     While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
>>>     that are "adjacent" for DOIC purposes may not be adjacent from a
>>>     Diameter, or transport, perspective.  For example, one or more
>>>     Diameter agents that do not support DOIC may exist between a given
>>>     pair of reporting and reacting nodes, as long as those agents pass
>>>     unknown AVPs through unchanged.  The report types described in this
>>>     document can safely pass through non-supporting agents.  This may not
>>>     be true for report types defined in future specifications.
>>>
>>> Comment: while this is all not wrong, the existing text may convey the erring
>>> impression that there cannot be a DOIC supporting agent on the path between a
>>> reporting node and an adjacent reacting node.
>>>
>>> Proposal: It is proposed to add the following sentence at the end of the paragraph:
>>>     Another example is where one or more Diameter agents that do support
>>>     DOIC may exist between a given pair of reporting and reacting nodes,
>>>     as long as those agents pass OC-specific AVPs through unchanged.
>>> I don't agree with the suggested change, as the DOIC supporting agents might need to change the OC-specific AVPs.
>>>  I agree that in some cases DOIC supporting agents need to change the OC-specific AVPs. However, there are also cases where DOIC supporting agents do not need to change OC-specific AVPs.
>>>    I also don't understand how the paragraph implies that there cannot be DOIC supporting agents in the path of the request.
>>>  It does not imply that. Rather it may convey the erring impression that there cannot be a DOIC supporting agent on the path between a
>>> reporting node and an adjacent reacting node.
>>>     It is talking specifically about the case where there agents do not support DOIC are in the path.
>>>  No, my understanding is that the paragraph is talking specifically about what "adjacent for DOIC purposes" means. One valid example is given (reporting node and reacting node are "adjacent for DOIC purposes" if one or more agents that do not support DOIC but pass unsupported AVPs through unchanged exist between reporting node and reacting node) and I do not propose to remove that. However, there is another important valid example (reporting node and reacting node are "adjacent for DOIC purposes" if one or more DOIC supporting agents that pass OC-specific AVPs through unchanged exist between reporting node and reacting node), and the proposal is to add text to cover this example. 
>>> The remainder of the document makes it clear that there can be agents that do support DOIC in the path of a transaction.
>>>  that is not my point. The point is to clearly state that there can be DOIC supporting agents that pass through OC-specific AVPs unchanged on the path between reporting node and reacting node, and in this case the reporting and reacting nodes are still regarded "adjacent for DOIC purposes".
>>>
>>> I don't see the need for a change here.
>>>  I'm not proposing a modification but an addition. This addition provides useful clarification and in no way is harmful
>>>
>>> Regards,
>>>
>>> Steve
>>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Thu Dec 11 05:54:07 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7725A1A3B9F for ; Thu, 11 Dec 2014 05:54:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZKDt_kOpChz for ; Thu, 11 Dec 2014 05:54:04 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E311A1B30 for ; Thu, 11 Dec 2014 05:54:04 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:58402 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Xz4Bt-000Ati-HO; Thu, 11 Dec 2014 05:54:03 -0800
Message-ID: <5489A1F9.906@usdonovans.com>
Date: Thu, 11 Dec 2014 07:54:01 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <54862D14.2060304@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235122@DEMUMBX014.nsn-intra.net> <54883DC2.20504@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235452@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815235452@DEMUMBX014.nsn-intra.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/DBqlUCwa-pjFoNBpPWclmzRUwlM
Subject: Re: [Dime] Ulrich suggested change number 2
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 13:54:05 -0000

I'm ok with this, as long as always is spelled correctly. :-)

Steve

On 12/10/14, 9:53 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
>
> How about something like this:
>
> "This ensures that a reporting node allways supports at least one of the advertized abatement algorithms received in a request messages."
>
> Regards
> Ulrich
>
>
> -----Original Message-----
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> Sent: Wednesday, December 10, 2014 1:34 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] Ulrich suggested change number 2
>
> Ulrich,
>
> How about changing the last sentence to:
>
> "This ensures that there is at least one commonly supported overload
> abatement algorithm supported by all DOIC nodes in the path of the request."
>
> Regards,
>
> Steve
>
> On 12/9/14, 8:08 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Steve,
>>
>> please see inline.
>>
>> Ulrich
>>
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>> Sent: Monday, December 08, 2014 11:58 PM
>> To: dime@ietf.org
>> Subject: [Dime] Ulrich suggested change number 2
>>
>> Ulrich,
>>
>> For the second suggested change:
>> Section 3.2, 6th paragraph:
>> Existing text:
>>      The OC-Feature-Vector AVP will contain an indication of support for
>>      the loss overload abatement algorithm defined in this specification
>>      (see Section 5).  This ensures that there is at least one commonly
>>      supported overload abatement algorithm between the reporting node and
>>      the reacting node(s) in the path of the request.
>>
>> Comment: I agree that within a given path between client and server there may
>> be more than one reacting nodes. But a given reporting node on that path does
>> not have more than one adjacent reacting nodes on that given path to which it
>> sends OLRs. I don't say that the existing text is wrong, but it is misleading.
>> What we want to say here is that any given pair of adjacent reacting and reporting
>> nodes will have at least one commonly supported algorithm.
>>
>> Proposal: It is proposed to replace the last line of the paragraph with:
>>      The adjacent reacting node on the path of the request.
>> It's more than just about the adjacent reaction nodes.  It is important that all reacting nodes in the path of the request have at least one common abatement algorithm.
>> I do not agree. It is important that a pair of two adjacent reacting and reporting nodes (A,S) have at least one commonly supported algorithm, so that the reporting node can always select an algorithm supported by the adjacent reacting node. There may be another (non-adjacent) reacting node in the path (C), but its not important for C and S (which are not adjacent) to have a commonly supported algorithm.
>> C---A---S
>> It is important that C and A have a commonly supported algorith, as C and A are adjacent;
>> It is important that A and S have a commonly supported algorith, as A and S are adjacent;
>> It is true but not important (and nothing that needs to be ensured) that C and S have a commonly supported algorithm (indeed S could eventually select an algorithm not supported by C);
>> It is true but not important that C, A and S have a commonly supported algorithm.
>>
>> I don't see the need for the suggested change.
>>
>> Regards,
>>
>> Steve
>>
>


From nobody Thu Dec 11 05:55:04 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFEB1A701A for ; Thu, 11 Dec 2014 05:55:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpZc7mUG28Wk for ; Thu, 11 Dec 2014 05:54:58 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26E111A1B30 for ; Thu, 11 Dec 2014 05:54:58 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:58403 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Xz4Ck-000Bvu-Id; Thu, 11 Dec 2014 05:54:57 -0800
Message-ID: <5489A22E.9040200@usdonovans.com>
Date: Thu, 11 Dec 2014 07:54:54 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Campbell 
References: <5486FCBF.4000707@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152351D9@DEMUMBX014.nsn-intra.net> <54883F5C.1060603@usdonovans.com> <7BF0F726-12CE-4236-8809-6B5E518F393D@nostrum.com>
In-Reply-To: <7BF0F726-12CE-4236-8809-6B5E518F393D@nostrum.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/wHLT7f_G2p11hvLIlcMbt5A5L_s
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change @12
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 13:55:02 -0000

Yes, I meant I do NOT see the need for a change.

Steve

On 12/10/14, 5:20 PM, Ben Campbell wrote:
>> On Dec 10, 2014, at 6:41 AM, Steve Donovan  wrote:
>>
>> Ulrich,
>>
>> This paragraph is talking about capability announcement.  We deal with the issues related to multiple sources of overload reports already elsewhere in the document.
>>
>> I still do see the need for a change.
> Those sentences seem contradictory, at least in town. Did you mean to say you do _not_ see the need for a change?
>
>> Steve
>>
>> On 12/9/14, 10:46 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>> Steve,
>>> I agree, my comment and proposal do not hit the mark.
>>>   
>>> The intention was to say that known issues exist if there are multiple agents on multiple paths between client and server. The agents may not be able to ensure that there is no ambiguity in DOIC behaviour for the client. E.g. from the client’s point of view the answer to a first request (which was modified by agent A1) could indicate: DOIC is supported, currenty no overload, once in overload loss will be selected; and the answer to the next request (which was modified by agent A2) could indicate: DOIC is supported, some?? reduction is requested using rate. The client, however, may not be prepared for rate.
>>>   
>>> Maybe a warning note could be added to say that the agent may not always be able to ensure that there is no ambiguity.
>>>   
>>> Ulrich
>>>   
>>>   
>>>   
>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>>> Sent: Tuesday, December 09, 2014 2:45 PM
>>> To: dime@ietf.org
>>> Subject: [Dime] Ulrich's suggested change @12
>>>   
>>> Ulrich,
>>>
>>> For your suggested change #12:
>>>
>>> Section 4.1.3, last paragraph:
>>> Existing text:
>>>     When making changes to the OC-Supported-Features AVP the Diameter
>>>     Agent needs to ensure that there is no ambiguity in DOIC behavior for
>>>     both upstream and downstream DOIC nodes.
>>>   
>>> Comment: while that is true, in addition problems similar to those
>>> identified in the note in section 3.3 may result from making changes.
>>>   
>>> Proposal: Add the note:
>>>        Note: Known issues exist if multiple sources for overload reports
>>>        which apply to the same Diameter entity exist.  Reacting nodes
>>>        have no way of determining the source and, as such, will treat
>>>        them as coming from a single source.  Variance in sequence numbers
>>>        between the two sources can then cause incorrect overload
>>>        abatement treatment to be applied for indeterminate periods of
>>>        time.
>>> I don't understand how these are related.  The change to the OC-Supported-Features AVP made by the agent apply only to the transaction.  In addition, this paragraph doesn't mention overload reports.
>>>
>>> Regards,
>>>
>>> Steve
>>>
>>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Thu Dec 11 06:03:10 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70141A88C0 for ; Thu, 11 Dec 2014 06:03:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yj_QQYuSgv1Y for ; Thu, 11 Dec 2014 06:03:07 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1906B1ACE47 for ; Thu, 11 Dec 2014 06:03:07 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:58413 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Xz4Kc-0008vM-Gy; Thu, 11 Dec 2014 06:03:06 -0800
Message-ID: <5489A416.2000403@usdonovans.com>
Date: Thu, 11 Dec 2014 08:03:02 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <5486FCBF.4000707@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152351D9@DEMUMBX014.nsn-intra.net> <54883F5C.1060603@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235675@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815235675@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------090302070700000800000502"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/oUqEOJQaY5SD_sGwycxEqmhQifM
Subject: Re: [Dime] Ulrich's suggested change @12
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 14:03:08 -0000

This is a multi-part message in MIME format.
--------------090302070700000800000502
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

I see your concern.  To summarize, if we have the following configuration:

    ----A1----
   /          \
  C            S
   \          /
    ----A2----

And A1 indicates loss in in the OC-S-F AVP in answer messages and A2 
indicates rate then there is ambiguity.

I agree, this warrants a warning statement somewhere in the document.

If there is general agreement on this then I'll propose wording and 
location.

Steve

On 12/11/14, 7:31 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
> yes, it's about capability announcement, and my concern in with 
> announcing the selected algorithm in answer messages (while no OLRs 
> are sent). Multiple  agents modifying the selected algorithm in the 
> Supported-Features AVPs in answer messages may  result in ambiguity in 
> DOIC behaviour for downstream DOIC nodes.
>
> Ulrich
>
> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Wednesday, December 10, 2014 1:41 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> *Subject:* Re: [Dime] Ulrich's suggested change @12
>
> Ulrich,
>
> This paragraph is talking about capability announcement.  We deal with 
> the issues related to multiple sources of overload reports already 
> elsewhere in the document.
>
> I still do see the need for a change.
>
> Steve
>
> On 12/9/14, 10:46 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Steve,
>
>     I agree, my comment and proposal do not hit the mark.
>
>     The intention was to say that known issues exist if there are
>     multiple agents on multiple paths between client and server. The
>     agents may not be able to ensure that there is no ambiguity in
>     DOIC behaviour for the client. E.g. from the client's point of
>     view the answer to a first request (which was modified by agent
>     A1) could indicate: DOIC is supported, currenty no overload, once
>     in overload loss will be selected; and the answer to the next
>     request (which was modified by agent A2) could indicate: DOIC is
>     supported, some?? reduction is requested using rate. The client,
>     however, may not be prepared for rate.
>
>     Maybe a warning note could be added to say that the agent may not
>     always be able to ensure that there is no ambiguity.
>
>     Ulrich
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext
>     Steve Donovan
>     *Sent:* Tuesday, December 09, 2014 2:45 PM
>     *To:* dime@ietf.org 
>     *Subject:* [Dime] Ulrich's suggested change @12
>
>     Ulrich,
>
>     For your suggested change #12:
>
>     Section 4.1.3, last paragraph:
>
>     Existing text:
>
>         When making changes to the OC-Supported-Features AVP the Diameter
>
>         Agent needs to ensure that there is no ambiguity in DOIC behavior for
>
>         both upstream and downstream DOIC nodes.
>
>       
>
>     Comment: while that is true, in addition problems similar to those
>
>     identified in the note in section 3.3 may result from making changes.
>
>       
>
>     Proposal: Add the note:
>
>            Note: Known issues exist if multiple sources for overload reports
>
>            which apply to the same Diameter entity exist.  Reacting nodes
>
>            have no way of determining the source and, as such, will treat
>
>            them as coming from a single source.  Variance in sequence numbers
>
>            between the two sources can then cause incorrect overload
>
>            abatement treatment to be applied for indeterminate periods of
>
>            time.
>
>     I don't understand how these are related.  The change to the
>     OC-Supported-Features AVP made by the agent apply only to the
>     transaction.  In addition, this paragraph doesn't mention overload
>     reports.
>
>     Regards,
>
>     Steve
>
>


--------------090302070700000800000502
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

    

    I see your concern.  To summarize, if we have the following
    configuration:

    

       ----A1----

        /          \

       C            S

        \          /

       ----A2----

    

    And A1 indicates loss in in the OC-S-F AVP in answer messages and A2
    indicates rate then there is ambiguity.  

    

    I agree, this warrants a warning statement somewhere in the
    document. 

    

    If there is general agreement on this then I'll propose wording and
    location.

    

    Steve

    

    
On 12/11/14, 7:31 AM, Wiehe, Ulrich
      (NSN - DE/Munich) wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
yes, it’s about capability announcement, and my
            concern in with announcing the selected algorithm in answer
            messages (while no OLRs are sent). Multiple  agents
            modifying the selected algorithm in the Supported-Features
            AVPs in answer messages may  result in ambiguity in DOIC
            behaviour for downstream DOIC nodes.

        
 

        
Ulrich

        
 

        

          

            
From: ext Steve Donovan
                [mailto:srdonovan@usdonovans.com]
                

                Sent: Wednesday, December 10, 2014 1:41 PM

                To: Wiehe, Ulrich (NSN - DE/Munich);
                dime@ietf.org

                Subject: Re: [Dime] Ulrich's suggested change @12

          

        

        
 

        
Ulrich,

          

          This paragraph is talking about capability announcement.  We
          deal with the issues related to multiple sources of overload
          reports already elsewhere in the document.

          

          I still do see the need for a change.

          

          Steve

        

          
On 12/9/14, 10:46 AM, Wiehe, Ulrich (NSN
            - DE/Munich) wrote:

        

        

          
Steve,

          
I agree, my comment
              and proposal do not hit the mark.

          
 

          
The intention was
              to say that known issues exist if there are multiple
              agents on multiple paths between client and server. The
              agents may not be able to ensure that there is no
              ambiguity in DOIC behaviour for the client. E.g. from the
              client’s point of view the answer to a first request
              (which was modified by agent A1) could indicate: DOIC is
              supported, currenty no overload, once in overload loss
              will be selected; and the answer to the next request
              (which was modified by agent A2) could indicate: DOIC is
              supported, some?? reduction is requested using rate. The
              client, however, may not be prepared for rate.

          
 

          
Maybe a warning
              note could be added to say that the agent may not always
              be able to ensure that there is no ambiguity.

          
 

          
Ulrich

          
 

          
 

          
 

          

            

              
From: DiME [mailto:dime-bounces@ietf.org]
                  On Behalf Of ext Steve Donovan

                  Sent: Tuesday, December 09, 2014 2:45 PM

                  To: dime@ietf.org

                  Subject: [Dime] Ulrich's suggested change @12

            

          

          
 

          
Ulrich,

            

            For your suggested change #12:

          
Section 4.1.3, last paragraph:

          
Existing text:

          
   When making changes to the OC-Supported-Features AVP the Diameter

          
   Agent needs to ensure that there is no ambiguity in DOIC behavior for

          
   both upstream and downstream DOIC nodes.

          
 

          
Comment: while that is true, in addition problems similar to those 

          
identified in the note in section 3.3 may result from making changes.

          
 

          
Proposal: Add the note:

          
      Note: Known issues exist if multiple sources for overload reports

          
      which apply to the same Diameter entity exist.  Reacting nodes

          
      have no way of determining the source and, as such, will treat

          
      them as coming from a single source.  Variance in sequence numbers

          
      between the two sources can then cause incorrect overload

          
      abatement treatment to be applied for indeterminate periods of

          
      time.

          
I don't
            understand how these are related.  The change to the
            OC-Supported-Features AVP made by the agent apply only to
            the transaction.  In addition, this paragraph doesn't
            mention overload reports.

            

            Regards,

            

            Steve

            

            

            

        

        
 

      

    

    

  


--------------090302070700000800000502--


From nobody Thu Dec 11 06:05:36 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A321ACE76 for ; Thu, 11 Dec 2014 06:05:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6xZrcwSn-5S for ; Thu, 11 Dec 2014 06:05:15 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC921ACE7C for ; Thu, 11 Dec 2014 06:05:14 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:58417 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Xz4Mi-000Bi5-Pg; Thu, 11 Dec 2014 06:05:13 -0800
Message-ID: <5489A498.5070203@usdonovans.com>
Date: Thu, 11 Dec 2014 08:05:12 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Campbell 
References: <5486FE71.70205@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235215@DEMUMBX014.nsn-intra.net> <54884137.4050209@usdonovans.com> <5AB8BAC5-3CBD-432E-9631-74DF40795844@nostrum.com>
In-Reply-To: <5AB8BAC5-3CBD-432E-9631-74DF40795844@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/tBgBJhWPs87oYoliqn63K2ZQU1w
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #15
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 14:05:18 -0000

I thought this paragraph was covering unrecognized values for all AVPs.  
Maybe it is better to remove the paragraph entirely and make sure that 
the definition of each AVP addresses what is done with unrecognized values.

Steve

On 12/10/14, 5:26 PM, Ben Campbell wrote:
>> On Dec 10, 2014, at 6:48 AM, Steve Donovan  wrote:
>>
>> Ulrich,
>>
>> Actually, the wording you suggested wasn't quite right.  It should be:
>>
>>    When receiving an OC-OLR AVP with unknown values, the overload report
>>    SHOULD be silently discarded by reacting nodes and the event SHOULD
>>    be logged.
>>
>> It's not just about report type values but unknown values for any of the AVPs in the OLR.
>>
>> This seems like a good requirement to include in the specification to ensure common behavior in reacting nodes.  I don't feel strongly about this but I would like to hear other opinions.
> I think this is still not quite complete.
>
> If you receive a sub-AVP that you don't understand, then you should ignore that sub-avp, not the whole OC-OLR AVP.  (Unless of course the unknown AVP has the m-bit set.) If you receive a known sub-AVP, with a value you don't understand, the behavior should be AVP specific. For Report-Type, that means ignore the whole OLR.
>
> It's not clear to me whether the original text was about arbitrary avps, or Report-Type.
>
>> Steve
>>
>> On 12/9/14, 11:04 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>> Hi Steve,
>>>
>>> I think it was pointed out by Ben that we do not specify behaviour of a node for cases where it detects that another node is breaking the rule.
>>> The rule is:
>>>     A reporting node MUST NOT send overload reports of a type that has
>>>     not been advertised as supported by the reacting node.
>>> See section 4.2.3.
>>>
>>> Regards
>>> Ulrich
>>>
>>>    
>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>>> Sent: Tuesday, December 09, 2014 2:52 PM
>>> To: dime@ietf.org
>>> Subject: [Dime] Ulrich's suggested change #15
>>>
>>> Ulrich,
>>>
>>> For your suggested change #15:
>>> Section 4.2.1.3, 4th paragraph:
>>> Existing text:
>>>     When receiving an OC-OLR AVPs with unknown values, a reacting node
>>>     SHOULD be silently discarded by reacting nodes and the event SHOULD
>>>     be logged.
>>> Comment: text is confusing. Maybe the intention was to say:
>>>     When receiving an OC-OLR AVPs with an unsupported report type value, a reacting node
>>>     SHOULD silently discarded the OC-OLR AVP and the event SHOULD
>>>     be logged.
>>> But even that is not correct.
>>> Proposal: Remove the paragraph.
>>> The intent was that an OC-OLR that contains unknown values should be discarded.  I agree that the wording needs to be changes as you suggested.  I don't agree with removing the paragraph.  Can you elaborate on why you think it is not correct when changed as you suggested?
>>>
>>> Regards,
>>>
>>> Steve
>>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Thu Dec 11 06:07:08 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E354E1A86FF for ; Thu, 11 Dec 2014 06:07:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfbwe5PQhZRs for ; Thu, 11 Dec 2014 06:07:05 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60DC1A1B65 for ; Thu, 11 Dec 2014 06:07:05 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:58422 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Xz4OV-00017e-04; Thu, 11 Dec 2014 06:07:05 -0800
Message-ID: <5489A506.1070700@usdonovans.com>
Date: Thu, 11 Dec 2014 08:07:02 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Campbell 
References: <548701E1.3060502@usdonovans.com> <6A70A6FF-1A7B-4372-BD05-B96C7DE69F9F@nostrum.com>
In-Reply-To: <6A70A6FF-1A7B-4372-BD05-B96C7DE69F9F@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XWyxF_GmMRmEYMPErU2y05gMrj4
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #16
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 14:07:07 -0000

Ben,

Diversion works for realm-routed requests in response to host reports.

See my proposed wording sent in an early email.

Steve

On 12/10/14, 5:42 PM, Ben Campbell wrote:
>> On Dec 9, 2014, at 8:06 AM, Steve Donovan  wrote:
>>
>> Ulrich,
>>
>> For your suggested change #16:
>>
>> Section 4.2.2, 5th and 6th paragraph:
>> Existing text:
>>     If the request is a host-routed request then the reacting node SHOULD
>>     apply throttling abatement treatment to the request.
>>   
>>     If the request is a realm-routed request then the reacting node
>>     SHOULD apply diversion abatement treatment to the request.
>>
>> Comment: I don't think so. If the reacting node selects the server and
>> then detects that the selected server is overloaded and then detects that
>> the request does not survive (i.e. is subject to abatement), then the reacting
>> node SHOULD apply diversion treatment (i.e. select an alternative server if possible).
>> If the reacting node does not select the server (either a. because the server was
>> already selected by a downstream node, or b. because the server will be selected
>> by an upstream node) then there is no point in applying diversion and the reacting
>> node SHOULD apply throttling of requests that do not survive.
>>
>> Proposal: replace the paragraphs with:
>>     If the reacting node does not select the server then it SHOULD apply
>>     throttling abatement to the request.
>>
>>     If the reacting node selects the server then it SHOULD apply diversion
>>     abatement treatment (i.e. select an alternative server if possible) to
>>     the request.
>>
>> Diversion is not selecting an alternative node to handle the request.  Diversion is selecting an alternative route to the selected node.
> Hmm. Isn't that only true for the proposed Peer-Report type in the Agent draft?
>
>>   
>>
>> Whether it is appropriate to select an alternative node for a request is an application decision that probably changes on a per command-code basis within the application.  Logic like this is outside the scope of the DOIC specification.
> So how does it work for existing applications? But I agree in principle. I somehow missed that we had 2119 language around this. I think the choice to apply diversion vs throttling should be local policy. We don't need to state it normatively.
>
>> The text is correct based on the definition of diversion.
> I'm not sure we have that definition right.
>
>> Regards,
>>
>> Steve
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Thu Dec 11 06:13:24 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777E21A895E for ; Thu, 11 Dec 2014 06:13:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRQ_VZkq0srV for ; Thu, 11 Dec 2014 06:13:20 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEBF81A6F13 for ; Thu, 11 Dec 2014 06:13:20 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:58429 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Xz4UX-0008aZ-HQ; Thu, 11 Dec 2014 06:13:19 -0800
Message-ID: <5489A67C.9060408@usdonovans.com>
Date: Thu, 11 Dec 2014 08:13:16 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <548701E1.3060502@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235234@DEMUMBX014.nsn-intra.net> <54884556.90108@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681523562D@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681523562D@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------020104020607010602050100"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dxb0-k1ZE0-Sc2xptR5sFG9RoLY
Subject: Re: [Dime] Ulrich's suggested change #16
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 14:13:22 -0000

This is a multi-part message in MIME format.
--------------020104020607010602050100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

There are two report types defined in the document -- host and realm.

There are two types of requests - host-routed and realm-routed.

This leaves four combinations for requests that are selected for 
abatement treatment:

If there is a host report and the request is host-routed then the 
abatement treatment should be to throttle the request.

If there is a host report and the request is realm-routed then the 
abatement treatment should be to divert the request.

If there is a realm report and the request is host-routed then the 
abatement treatment should be to throttle the request.

If there is a realm report and the request is realm-routed then the 
abatement treatment should be to divert the request.

If we agree to the above then we can come up with the proper wording.

Steve


On 12/11/14, 6:40 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
> I find your new proposal more confusing.
>
> I still think my original proposal is preferred. In addition the 
> definition for diversion may need to be updated.
>
> Regards
>
> Ulrich
>
> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Wednesday, December 10, 2014 2:07 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> *Subject:* Re: [Dime] Ulrich's suggested change #16
>
> Ulrich,
>
> I agree with your assumptions below.  For the third one, the only time 
> it is possible, at least from a DOIC perspective, to send to another 
> host is if it is a realm-routed request.  I might also change the "not 
> overloaded" to "less overloaded".
>
> I do think the statements can be improved to differentiate between 
> behavior for host reports and realm reports.
>
> How about the following:
>
>     For OLRs of type host, if the request is a host-routed request then the reacting node SHOULD
>     apply throttling abatement treatment to the request.
>   
>     For OLRs of type host, If the request is a realm-routed request then the reacting node
>     SHOULD apply diversion abatement treatment to the request.
>     For OLRs of type realm, the reacting node SHOULD
>     apply throttling abatement treatment to the request, independent of the type (host-routed or
>     realm-routed) of request.
>   
>
> Regards,
>
> Steve
>
> On 12/9/14, 11:29 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Steve,
>
>     yes, then, maybe, the definition of Diversion is not correct?
>
>     What are other people's views?
>
>       
>
>     My assumption was:
>
>     If a host is overloaded, it does not help to direct traffic to that host via a different path.
>
>     If a realm is overloaded, it does not help to direct traffic to that realm via a different path.
>
>     If a host is overloaded, it helps to select an alternative (not overloaded) host (if possible) and direct traffic to that host.
>
>     If a realm is overloaded, there never is an alternative (not overloaded) realm to which traffic could be directed.
>
>       
>
>     With the current definition of Diversion, Diversion is no appropriate means to address host overload and is no appropriate means to address realm overload. It may be ok for agent overload only.
>
>       
>
>     Regards
>
>     Ulrich
>
>       
>
>     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>
>     Sent: Tuesday, December 09, 2014 3:06 PM
>
>     To:dime@ietf.org  
>
>     Subject: [Dime] Ulrich's suggested change #16
>
>       
>
>     Ulrich,
>
>       
>
>     For your suggested change #16:
>
>     Section 4.2.2, 5th and 6th paragraph:
>
>     Existing text:
>
>         If the request is a host-routed request then the reacting node SHOULD
>
>         apply throttling abatement treatment to the request.
>
>       
>
>         If the request is a realm-routed request then the reacting node
>
>         SHOULD apply diversion abatement treatment to the request.
>
>       
>
>     Comment: I don't think so. If the reacting node selects the server and
>
>     then detects that the selected server is overloaded and then detects that
>
>     the request does not survive (i.e. is subject to abatement), then the reacting
>
>     node SHOULD apply diversion treatment (i.e. select an alternative server if possible).
>
>     If the reacting node does not select the server (either a. because the server was
>
>     already selected by a downstream node, or b. because the server will be selected
>
>     by an upstream node) then there is no point in applying diversion and the reacting
>
>     node SHOULD apply throttling of requests that do not survive.
>
>       
>
>     Proposal: replace the paragraphs with:
>
>         If the reacting node does not select the server then it SHOULD apply
>
>         throttling abatement to the request.
>
>       
>
>         If the reacting node selects the server then it SHOULD apply diversion
>
>         abatement treatment (i.e. select an alternative server if possible) to
>
>         the request.
>
>     Diversion is not selecting an alternative node to handle the request.  Diversion is selecting an alternative route to the selected node.
>
>       
>
>     Whether it is appropriate to select an alternative node for a request is an application decision that probably changes on a per command-code basis within the application.  Logic like this is outside the scope of the DOIC specification.
>
>       
>
>     The text is correct based on the definition of diversion.
>
>       
>
>     Regards,
>
>       
>
>     Steve
>
>       
>


--------------020104020607010602050100
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

    

    There are two report types defined in the document -- host and
    realm.

    

    There are two types of requests - host-routed and realm-routed.

    

    This leaves four combinations for requests that are selected for
    abatement treatment:

    

    If there is a host report and the request is host-routed then the
    abatement treatment should be to throttle the request.

    

    If there is a host report and the request is realm-routed then the
    abatement treatment should be to divert the request.

    

    If there is a realm report and the request is host-routed then the
    abatement treatment should be to throttle the request.

    

    If there is a realm report and the request is realm-routed then the
    abatement treatment should be to divert the request.

    

    If we agree to the above then we can come up with the proper
    wording.

    

    Steve

    

    

    
On 12/11/14, 6:40 AM, Wiehe, Ulrich
      (NSN - DE/Munich) wrote:

    

    

      
      
      
      

        
Steve,

        
I find your new proposal more confusing.

        
 

        
I still think my original proposal is
            preferred. In addition the definition for diversion may need
            to be updated.

        
 

        
Regards

        
Ulrich

        
 

        

          

            
From: ext Steve Donovan
                [mailto:srdonovan@usdonovans.com]
                

                Sent: Wednesday, December 10, 2014 2:07 PM

                To: Wiehe, Ulrich (NSN - DE/Munich);
                dime@ietf.org

                Subject: Re: [Dime] Ulrich's suggested change #16

          

        

        
 

        
Ulrich,

          

          I agree with your assumptions below.  For the third one, the
          only time it is possible, at least from a DOIC perspective, to
          send to another host is if it is a realm-routed request.  I
          might also change the "not overloaded" to "less overloaded".

          

          I do think the statements can be improved to differentiate
          between behavior for host reports and realm reports.

          

          How about the following:

        
   For OLRs of type host, if the request is a host-routed request then the reacting node SHOULD

        
   apply throttling abatement treatment to the request.

        
 

        
   For OLRs of type host, If the request is a realm-routed request then the reacting node

        
   SHOULD apply diversion abatement treatment to the request.

        
   For OLRs of type realm, the reacting node SHOULD

        
   apply throttling abatement treatment to the request, independent of the type (host-routed or 

        
   realm-routed) of request.

        
 

        
Regards,

          

          Steve

        

          
On 12/9/14, 11:29 AM, Wiehe, Ulrich (NSN
            - DE/Munich) wrote:

        

        

          
Steve,

          
yes, then, maybe, the definition of Diversion is not correct?

          
What are other people's views?

          
 

          
My assumption was:

          
If a host is overloaded, it does not help to direct traffic to that host via a different path.

          
If a realm is overloaded, it does not help to direct traffic to that realm via a different path.

          
If a host is overloaded, it helps to select an alternative (not overloaded) host (if possible) and direct traffic to that host.

          
If a realm is overloaded, there never is an alternative (not overloaded) realm to which traffic could be directed.

          
 

          
With the current definition of Diversion, Diversion is no appropriate means to address host overload and is no appropriate means to address realm overload. It may be ok for agent overload only.

          
 

          
Regards

          
Ulrich

          
 

          
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan

          
Sent: Tuesday, December 09, 2014 3:06 PM

          
To: dime@ietf.org

          
Subject: [Dime] Ulrich's suggested change #16

          
 

          
Ulrich,

          
 

          
For your suggested change #16:

          
Section 4.2.2, 5th and 6th paragraph:

          
Existing text:

          
   If the request is a host-routed request then the reacting node SHOULD

          
   apply throttling abatement treatment to the request.

          
 

          
   If the request is a realm-routed request then the reacting node

          
   SHOULD apply diversion abatement treatment to the request.

          
 

          
Comment: I don't think so. If the reacting node selects the server and 

          
then detects that the selected server is overloaded and then detects that 

          
the request does not survive (i.e. is subject to abatement), then the reacting 

          
node SHOULD apply diversion treatment (i.e. select an alternative server if possible). 

          
If the reacting node does not select the server (either a. because the server was 

          
already selected by a downstream node, or b. because the server will be selected 

          
by an upstream node) then there is no point in applying diversion and the reacting 

          
node SHOULD apply throttling of requests that do not survive.

          
 

          
Proposal: replace the paragraphs with:

          
   If the reacting node does not select the server then it SHOULD apply

          
   throttling abatement to the request.

          
 

          
   If the reacting node selects the server then it SHOULD apply diversion

          
   abatement treatment (i.e. select an alternative server if possible) to

          
   the request.

          
Diversion is not selecting an alternative node to handle the request.  Diversion is selecting an alternative route to the selected node.  

          
 

          
Whether it is appropriate to select an alternative node for a request is an application decision that probably changes on a per command-code basis within the application.  Logic like this is outside the scope of the DOIC specification.

          
 

          
The text is correct based on the definition of diversion.

          
 

          
Regards,

          
 

          
Steve

          
 

        

        
 

      

    

    

  


--------------020104020607010602050100--


From nobody Thu Dec 11 06:18:03 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87D21A1BE9 for ; Thu, 11 Dec 2014 06:18:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msSjMpcyJ5wU for ; Thu, 11 Dec 2014 06:17:59 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A891ACECD for ; Thu, 11 Dec 2014 06:17:08 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:58436 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Xz4Y7-0000Bs-VL; Thu, 11 Dec 2014 06:17:07 -0800
Message-ID: <5489A75B.6020106@usdonovans.com>
Date: Thu, 11 Dec 2014 08:16:59 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  ext Ben Campbell 
References: <5486F0F1.8000200@usdonovans.com>  <5BCBA1FC2B7F0B4C9D935572D900066815235600@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815235600@DEMUMBX014.nsn-intra.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xzOER8XWk3D5vat7zQR_qajRr-s
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggest change number 6
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 14:18:01 -0000

+1

On 12/11/14, 5:36 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> The proposed simplification is ok for me.
> Ulrich
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
> Sent: Wednesday, December 10, 2014 11:02 PM
> To: Steve Donovan
> Cc: dime@ietf.org
> Subject: Re: [Dime] Ulrich's suggest change number 6
>
>
>> On Dec 9, 2014, at 6:54 AM, Steve Donovan  wrote:
>>
>> Ulrich,
>>
>> For your suggested change #6:
>>
>> Section 3.3, 12th paragraph:
>> Existing text:
>>     As the conditions that lead to the generation of the overload report
>>     change the reporting node can send new overload reports requesting
>>     greater reduction if the condition gets worse or less reduction if
>>     the condition improves.  The reporting node sends an overload report
>>     with a duration of zero to indicate that the overload condition has
>>     ended and need for use of the abatement algorithm to reduce traffic
>>     sent is no longer needed.
>> Comment: Bad style.
>> Proposal: Remove the words "need for" from the last sentence.
>>
>> I support the suggested change.
> If we are going to change it, I propose a further simplification of the last sentence:
>
> "... and abatement is no longer needed."
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Thu Dec 11 06:45:38 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232F61ACEE3 for ; Thu, 11 Dec 2014 06:45:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Level: 
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZsFUI7mpw9E for ; Thu, 11 Dec 2014 06:45:28 -0800 (PST)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4D41ACF00 for ; Thu, 11 Dec 2014 06:45:28 -0800 (PST)
Received: by mail-lb0-f177.google.com with SMTP id b6so4079156lbj.8 for ; Thu, 11 Dec 2014 06:45:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8SVFgaZjxpkuIJ/F61YVhxE50hbp1iulE3VtQHXQtyE=; b=XfQA2y+TFfV6icc/hgjFRopK2EyjJfvTsXckzTvGN0aKqww0oDHkJyjMU6TD97imO0 sq3eeF0mltwZkGoxlSE5QWyF9FX8bwlaD/3YwLp04yOWWfxgk7nrQVms/lF2dZBBbkS8 LEszrRcnM0p9+mtDY6l8OIoLnq6du8ac7kjpmEAwmrT34huYDQ31WXb7+KvZKOJH4pNI N9I18s3uEXNocyOgms2JI9wBWTj0ycR2TUJacYvYWfF6hkGAaPn5+qdHgWgwo0Odht91 YYRRB2q+9niLxfklo2YhLRdKBzD5IcO97ABgt1ZubGUFIXC0tAEdX8Wpx/Q+cZWYoRcQ YN0w==
X-Received: by 10.152.6.67 with SMTP id y3mr8737189lay.90.1418309126873; Thu, 11 Dec 2014 06:45:26 -0800 (PST)
Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPSA id v8sm454523lae.6.2014.12.11.06.45.25 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Dec 2014 06:45:25 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Jouni 
In-Reply-To: <4A9D369D-E22C-4E21-A887-C9123C23D017@gmail.com>
Date: Thu, 11 Dec 2014 16:45:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4A9D369D-E22C-4E21-A887-C9123C23D017@gmail.com>
To: "dime@ietf.org list" 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2aBk0c0_iEnjrfOXnlPqA-VmsY8
Subject: Re: [Dime] DIME and adding "load information" to the charter milestones
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 14:45:31 -0000

Folks,

There was no objection, thus we will add the two milestones listed below =
to our charter.

- Jouni & Lionel


> On 03 Dec 2014, at 12:04, Jouni  wrote:
>=20
> Folks,
>=20
> As we discussed in Honolulu there is interest to add a new milestone =
for the load information. Recap from the meeting minutes:
>=20
>  Ben - we have a path forward for now. Not working group adoption. We =
don't
>        have a milestone for load. Although it's implied with solving =
RFC7068
>=20
>  Jouni - Who supports adding load to milestones? (7 hands) Against? (0
>          hands).
>=20
>  ACTION: Ask the mailing list about adding load to the milestones.
>=20
> So, we are going to add the following milestones (subject to editing) =
unless
> enough people express their disagreement by 11th Dec EOB (CET+1):
>=20
> Mar 2015 - Submit a document on 'Diameter Load Information' as a =
working group item
> Mar 2016 - Submit I-D 'Diameter Load Information' to the IESG for =
consideration as a Proposed Standard
>=20
>=20
> - Jouni & Lionel


From nobody Thu Dec 11 07:31:02 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163641A1B1D for ; Thu, 11 Dec 2014 07:31:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-qFWHbTWx3G for ; Thu, 11 Dec 2014 07:31:00 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2B31A1B44 for ; Thu, 11 Dec 2014 07:30:59 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: dime@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141211153059.23934.76924.idtracker@ietfa.amsl.com>
Date: Thu, 11 Dec 2014 07:30:59 -0800
From: IETF Secretariat 
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/lcuBCBwrhYquP4XzNxpVY_o5oVw
Subject: [Dime] Milestones changed for dime WG
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 15:31:01 -0000

URL: http://datatracker.ietf.org/wg/dime/charter/


From nobody Thu Dec 11 10:29:58 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C903F1A8835 for ; Thu, 11 Dec 2014 10:29:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0BBI6yCUaTZ for ; Thu, 11 Dec 2014 10:29:46 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 223561A879F for ; Thu, 11 Dec 2014 10:29:46 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBBITiCu019134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2014 12:29:45 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815235657@DEMUMBX014.nsn-intra.net>
Date: Thu, 11 Dec 2014 12:29:44 -0600
X-Mao-Original-Outgoing-Id: 440015384.463196-23852e8237cb8cc4e22c9ce46508aae0
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5486F59E.4000908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235197@DEMUMBX014.nsn-intra.net> <57CA5812-ABE6-4974-8632-1BC40FA84082@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D900066815235657@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/MO1mHhALj6MYlpZe7PkaUOATx2k
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #8
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 18:29:49 -0000

> On Dec 11, 2014, at 7:16 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:
>=20
> Ben,
> would the following proposed text address your concern:
>=20
>   A reporting node MUST NOT change the selected algorithm during the =
period
>   of time that starts when entering an overload condition and ends =
when it
>   is ensured that any non-expired reacting node's OCS entry created as =
a
>   result of the overload condition in the reporting node is deleted.
>=20

Yes, although I might suggest:

  "A reporting node MUST NOT change the selected algorithm during the =
period
  of time that starts when entering an overload condition and ends when =
the associated=20
  OCS becomes invalid in all reacting nodes."
=20
> In addition, is it so that outside that period the algorithm change =
can occur arbitrarily?
> e.g. is it ok to change the algorithm in every second answer message =
while outside the period?
> Or, is it ok to send rate while outside the period and send loss once =
the overload condition is entered?
> Note that section 3.2. says:
>=20
>   Reacting nodes can use the indicated overload abatement algorithm to
>   prepare for possible overload reports
>=20
> Should we recommend not to change the algorithm too often while =
outside the periode where change is prohibited?

For "loss", it does not matter. But for algorithms that require reacting =
nodes to keep state, it might matter. In my opinion, reporting nodes
should not change the algorithm very often, and not without good reason. =
But I don't think that needs to be a normative requirement.

>=20
> Regards
> Ulrich
>=20
> -----Original Message-----
> From: ext Ben Campbell [mailto:ben@nostrum.com]=20
> Sent: Wednesday, December 10, 2014 11:58 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: ext Steve Donovan; dime@ietf.org
> Subject: Re: [Dime] Ulrich's suggested change #8
>=20
>=20
>> On Dec 9, 2014, at 9:30 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:
>>=20
>> Steve,
>>=20
>> please see inline.
>>=20
>> Ulrich
>>=20
>>=20
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve =
Donovan
>> Sent: Tuesday, December 09, 2014 2:14 PM
>> To: dime@ietf.org
>> Subject: [Dime] Ulrich's suggested change #8
>>=20
>> Ulrich,
>>=20
>> For your suggested change number 8:
>> Section 4.1.2, 8th paragraph:
>> Existing text:
>>  For an ongoing overload condition, a reporting node MUST NOT change
>>  the selected algorithm during the period of time that it is in an
>>  overload condition and, as a result, is sending OC-OLR AVPs in =
answer
>>  messages.
>>=20
>> Comment: As a result of an ongoing overload condition the reporting =
node is=20
>> sending OC-OLR AVPs containing no validity duration or a validity =
duration=20
>> different from zero in answer messages.
>>=20
>> Proposal: Replace the paragraph with:
>>  For an ongoing overload condition, a reporting node MUST NOT change
>>  the selected algorithm during the period of time that it is in an
>>  overload condition and, as a result, is sending OC-OLR AVPs
>>  containing no validity duration or a validity duration different
>>  from zero in answer messages.
>> I don't see the need for the change.  The selected algorithm should =
not change for all overload reports relating to an overload condition, =
including overload reports with a validity duration of zero.
>>  Isn't it so that when the overload condition ends (i.e. is =
no longer ongoing), the reporting node starts sending OLRs with validity =
duration of zero (for a long enough period of time)? (see end of section =
4.2.1.4)=20
>> The question now is whether the change of algorithm is allowed during =
this (long enough) period, or only after that period. I don't have a =
strong view. But this was not my point.
>> My point is that the current text seems to suggest that an overload =
condition is ongoing as long as OC-OLR AVPs are sent in answer messages, =
and I think that is not true. 
>>=20
>=20
> I think the proscription should last until the reporting node is (at =
least reasonably) sure that all reacting nodes have removed the OCS. The =
original text comes closer to that than Ulrich's proposal, but I wonder =
if we shouldn't cast this in similar terms as we do for the part about =
resending zero duration OLRs.
>=20


From nobody Thu Dec 11 10:38:45 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74F31A8934 for ; Thu, 11 Dec 2014 10:38:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjNS8w_zUL8f for ; Thu, 11 Dec 2014 10:38:34 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A86091A87E2 for ; Thu, 11 Dec 2014 10:38:33 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBBIcWAr019983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2014 12:38:33 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5489A416.2000403@usdonovans.com>
Date: Thu, 11 Dec 2014 12:38:32 -0600
X-Mao-Original-Outgoing-Id: 440015912.273385-8621adf89bf48d682f364250f12a27e0
Content-Transfer-Encoding: quoted-printable
Message-Id: <64AB1BC6-8D34-4DEB-B801-C5C127047C8C@nostrum.com>
References: <5486FCBF.4000707@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152351D9@DEMUMBX014.nsn-intra.net> <54883F5C.1060603@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235675@DEMUMBX014.nsn-intra.net> <5489A416.2000403@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XqXb_W1MnmUW5nVrng2WPRjSjwQ
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change @12
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 18:38:39 -0000

> On Dec 11, 2014, at 8:03 AM, Steve Donovan  =
wrote:
>=20
> Ulrich,
>=20
> I see your concern.  To summarize, if we have the following =
configuration:
>=20
>    ----A1----
>   /          \
>  C            S
>   \          /
>    ----A2----
>=20
> And A1 indicates loss in in the OC-S-F AVP in answer messages and A2 =
indicates rate then there is ambiguity. =20
>=20
> I agree, this warrants a warning statement somewhere in the document.=20=

>=20
> If there is general agreement on this then I'll propose wording and =
location.
>=20

What sort of guidance should we give here? IMO, this is a worse problem =
than for realm reports, or at least having it for both realm and host =
reports makes it considerably worse than before. I think variations on =
this will happen for almost any Diameter network of non-trivial size.

I also think it's reasonable that A1 and A2 might select different =
algorithms towards C. For example, lets say C, A1, and S all support =
rate, but A2 does not. S might select rate towards A1, but loss towards =
A2.

If we can't handle this, I think the entire solution breaks down.

I propose that the best way to handle this is to add source-attribution =
into OLRs, and guidance for what C should do if it gets different =
capabilities for the same host or realm from different paths. This =
_might_ also help solve the "different reports for same realm" problem =
and the "can't tell if an intervening agent supports DOIC" problem.=20


> Steve
>=20
> On 12/11/14, 7:31 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Steve,
>> =20
>> yes, it=92s about capability announcement, and my concern in with =
announcing the selected algorithm in answer messages (while no OLRs are =
sent). Multiple  agents modifying the selected algorithm in the =
Supported-Features AVPs in answer messages may  result in ambiguity in =
DOIC behaviour for downstream DOIC nodes.
>> =20
>> Ulrich
>> =20
>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
>> Sent: Wednesday, December 10, 2014 1:41 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
>> Subject: Re: [Dime] Ulrich's suggested change @12
>> =20
>> Ulrich,
>>=20
>> This paragraph is talking about capability announcement.  We deal =
with the issues related to multiple sources of overload reports already =
elsewhere in the document.
>>=20
>> I still do see the need for a change.
>>=20
>> Steve
>>=20
>> On 12/9/14, 10:46 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Steve,
>> I agree, my comment and proposal do not hit the mark.
>> =20
>> The intention was to say that known issues exist if there are =
multiple agents on multiple paths between client and server. The agents =
may not be able to ensure that there is no ambiguity in DOIC behaviour =
for the client. E.g. from the client=92s point of view the answer to a =
first request (which was modified by agent A1) could indicate: DOIC is =
supported, currenty no overload, once in overload loss will be selected; =
and the answer to the next request (which was modified by agent A2) =
could indicate: DOIC is supported, some?? reduction is requested using =
rate. The client, however, may not be prepared for rate.
>> =20
>> Maybe a warning note could be added to say that the agent may not =
always be able to ensure that there is no ambiguity.
>> =20
>> Ulrich
>> =20
>> =20
>> =20
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve =
Donovan
>> Sent: Tuesday, December 09, 2014 2:45 PM
>> To: dime@ietf.org
>> Subject: [Dime] Ulrich's suggested change @12
>> =20
>> Ulrich,
>>=20
>> For your suggested change #12:
>>=20
>> Section 4.1.3, last paragraph:
>> Existing text:
>>    When making changes to the OC-Supported-Features AVP the Diameter
>>    Agent needs to ensure that there is no ambiguity in DOIC behavior =
for
>>    both upstream and downstream DOIC nodes.
>> =20
>> Comment: while that is true, in addition problems similar to those=20
>> identified in the note in section 3.3 may result from making changes.
>> =20
>> Proposal: Add the note:
>>       Note: Known issues exist if multiple sources for overload =
reports
>>       which apply to the same Diameter entity exist.  Reacting nodes
>>       have no way of determining the source and, as such, will treat
>>       them as coming from a single source.  Variance in sequence =
numbers
>>       between the two sources can then cause incorrect overload
>>       abatement treatment to be applied for indeterminate periods of
>>       time.
>> I don't understand how these are related.  The change to the =
OC-Supported-Features AVP made by the agent apply only to the =
transaction.  In addition, this paragraph doesn't mention overload =
reports.
>>=20
>> Regards,
>>=20
>> Steve
>>=20
>>=20
>>=20
>> =20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Thu Dec 11 10:45:06 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2721A1BA0 for ; Thu, 11 Dec 2014 10:45:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nldrh1T8gV6k for ; Thu, 11 Dec 2014 10:45:03 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21D9B1A6FC0 for ; Thu, 11 Dec 2014 10:45:03 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBBIj1MR020485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2014 12:45:02 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815235522@DEMUMBX014.nsn-intra.net>
Date: Thu, 11 Dec 2014 12:45:01 -0600
X-Mao-Original-Outgoing-Id: 440016301.770056-26b7a1a0cb895d3627a117eeb851103f
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5486FE71.70205@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235215@DEMUMBX014.nsn-intra.net> <54884137.4050209@usdonovans.com> <5AB8BAC5-3CBD-432E-9631-74DF40795844@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D900066815235522@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/tTMDrb4i6XsmuE8b3QsHKQt2qeY
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #15
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 18:45:06 -0000

> On Dec 11, 2014, at 2:32 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:
>=20
> Ben,
> for my clarification:
> you wrote: "If you receive a known sub-AVP, with a value you don't =
understand, the behavior should be AVP specific. For Report-Type, that =
means ignore the whole OLR."
>=20
> I would have thought that "For Report-Type, that means ignore the =
whole set of OLRs".
> At least it should be allowed to do that.
>=20
> The requirement for the reporting node is to not send OLRs with report =
type values that are unknown/unsupported by the reacting node.=20
> The reporting node cannot assume that, when breaking this rule, the =
reacting node will act in a predictable way.

 I think we should allow ignoring the whole set, but not require that. =
Postel's Maxim might suggest that if there are other properly =
constructed OLRs, the reacting node can still reasonably assume that the =
reporting node meant them, but it's up to the implementation.


> It should even be ok for the reporting node to ignore the complete =
answer message.
>=20

Except that. I don't think we _ever_ want a DOIC error to cause the =
enclosing transaction to fail.

> Please let me know your comments.
>=20
> Ulrich
>=20
>=20
> -----Original Message-----
> From: ext Ben Campbell [mailto:ben@nostrum.com]=20
> Sent: Thursday, December 11, 2014 12:26 AM
> To: Steve Donovan
> Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] Ulrich's suggested change #15
>=20
>>=20
>> On Dec 10, 2014, at 6:48 AM, Steve Donovan  =
wrote:
>>=20
>> Ulrich,
>>=20
>> Actually, the wording you suggested wasn't quite right.  It should =
be:
>>=20
>>  When receiving an OC-OLR AVP with unknown values, the overload =
report
>>  SHOULD be silently discarded by reacting nodes and the event SHOULD
>>  be logged.
>>=20
>> It's not just about report type values but unknown values for any of =
the AVPs in the OLR.
>>=20
>> This seems like a good requirement to include in the specification to =
ensure common behavior in reacting nodes.  I don't feel strongly about =
this but I would like to hear other opinions.
>=20
> I think this is still not quite complete.
>=20
> If you receive a sub-AVP that you don't understand, then you should =
ignore that sub-avp, not the whole OC-OLR AVP.  (Unless of course the =
unknown AVP has the m-bit set.) If you receive a known sub-AVP, with a =
value you don't understand, the behavior should be AVP specific. For =
Report-Type, that means ignore the whole OLR.
>=20
> It's not clear to me whether the original text was about arbitrary =
avps, or Report-Type.
>=20
>>=20
>> Steve
>>=20
>> On 12/9/14, 11:04 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>> Hi Steve,
>>>=20
>>> I think it was pointed out by Ben that we do not specify behaviour =
of a node for cases where it detects that another node is breaking the =
rule.
>>> The rule is:
>>>   A reporting node MUST NOT send overload reports of a type that has
>>>   not been advertised as supported by the reacting node.
>>> See section 4.2.3.
>>>=20
>>> Regards
>>> Ulrich
>>>=20
>>>=20
>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve =
Donovan
>>> Sent: Tuesday, December 09, 2014 2:52 PM
>>> To: dime@ietf.org
>>> Subject: [Dime] Ulrich's suggested change #15
>>>=20
>>> Ulrich,
>>>=20
>>> For your suggested change #15:
>>> Section 4.2.1.3, 4th paragraph:
>>> Existing text:
>>>   When receiving an OC-OLR AVPs with unknown values, a reacting node
>>>   SHOULD be silently discarded by reacting nodes and the event =
SHOULD
>>>   be logged.
>>> Comment: text is confusing. Maybe the intention was to say:
>>>   When receiving an OC-OLR AVPs with an unsupported report type =
value, a reacting node
>>>   SHOULD silently discarded the OC-OLR AVP and the event SHOULD
>>>   be logged.
>>> But even that is not correct.
>>> Proposal: Remove the paragraph.
>>> The intent was that an OC-OLR that contains unknown values should be =
discarded.  I agree that the wording needs to be changes as you =
suggested.  I don't agree with removing the paragraph.  Can you =
elaborate on why you think it is not correct when changed as you =
suggested?
>>>=20
>>> Regards,
>>>=20
>>> Steve
>>>=20
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20


From nobody Thu Dec 11 10:51:26 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAB11A1ADF for ; Thu, 11 Dec 2014 10:51:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbTtBcZz-Vli for ; Thu, 11 Dec 2014 10:51:22 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 845241A1BA0 for ; Thu, 11 Dec 2014 10:51:19 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBBIpICn021063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2014 12:51:19 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5489A498.5070203@usdonovans.com>
Date: Thu, 11 Dec 2014 12:51:18 -0600
X-Mao-Original-Outgoing-Id: 440016678.183841-2090af434d105740dde7229991e2e7f4
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5486FE71.70205@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235215@DEMUMBX014.nsn-intra.net> <54884137.4050209@usdonovans.com> <5AB8BAC5-3CBD-432E-9631-74DF40795844@nostrum.com> <5489A498.5070203@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7Z57Bv2aT-UJMKT8Uiy4JsJH0p4
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #15
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 18:51:24 -0000

> On Dec 11, 2014, at 8:05 AM, Steve Donovan  =
wrote:
>=20
> I thought this paragraph was covering unrecognized values for all =
AVPs.

I agree that's what it covered. But I think we failed to cover the =
unrecognized AVP case. If we don't have anything to say beyond what 6733 =
says, then it might not be strictly necessary, but it might still be =
worth saying that "unrecognized sub-AVPs are treated as per RFC6733".


>  Maybe it is better to remove the paragraph entirely and make sure =
that the definition of each AVP addresses what is done with unrecognized =
values.

Possibly. There are AVPs where there's no such thing as an unrecognized =
value. There may be AVPs where the allowed values vary by algorithm. If =
we do take that route, we probably need language here that says =
unrecognized values are handled as described by the AVP definition or =
the algorithm.

>=20
> Steve
>=20
> On 12/10/14, 5:26 PM, Ben Campbell wrote:
>>> On Dec 10, 2014, at 6:48 AM, Steve Donovan =
 wrote:
>>>=20
>>> Ulrich,
>>>=20
>>> Actually, the wording you suggested wasn't quite right.  It should =
be:
>>>=20
>>>   When receiving an OC-OLR AVP with unknown values, the overload =
report
>>>   SHOULD be silently discarded by reacting nodes and the event =
SHOULD
>>>   be logged.
>>>=20
>>> It's not just about report type values but unknown values for any of =
the AVPs in the OLR.
>>>=20
>>> This seems like a good requirement to include in the specification =
to ensure common behavior in reacting nodes.  I don't feel strongly =
about this but I would like to hear other opinions.
>> I think this is still not quite complete.
>>=20
>> If you receive a sub-AVP that you don't understand, then you should =
ignore that sub-avp, not the whole OC-OLR AVP.  (Unless of course the =
unknown AVP has the m-bit set.) If you receive a known sub-AVP, with a =
value you don't understand, the behavior should be AVP specific. For =
Report-Type, that means ignore the whole OLR.
>>=20
>> It's not clear to me whether the original text was about arbitrary =
avps, or Report-Type.
>>=20
>>> Steve
>>>=20
>>> On 12/9/14, 11:04 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>> Hi Steve,
>>>>=20
>>>> I think it was pointed out by Ben that we do not specify behaviour =
of a node for cases where it detects that another node is breaking the =
rule.
>>>> The rule is:
>>>>    A reporting node MUST NOT send overload reports of a type that =
has
>>>>    not been advertised as supported by the reacting node.
>>>> See section 4.2.3.
>>>>=20
>>>> Regards
>>>> Ulrich
>>>>=20
>>>>   From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve =
Donovan
>>>> Sent: Tuesday, December 09, 2014 2:52 PM
>>>> To: dime@ietf.org
>>>> Subject: [Dime] Ulrich's suggested change #15
>>>>=20
>>>> Ulrich,
>>>>=20
>>>> For your suggested change #15:
>>>> Section 4.2.1.3, 4th paragraph:
>>>> Existing text:
>>>>    When receiving an OC-OLR AVPs with unknown values, a reacting =
node
>>>>    SHOULD be silently discarded by reacting nodes and the event =
SHOULD
>>>>    be logged.
>>>> Comment: text is confusing. Maybe the intention was to say:
>>>>    When receiving an OC-OLR AVPs with an unsupported report type =
value, a reacting node
>>>>    SHOULD silently discarded the OC-OLR AVP and the event SHOULD
>>>>    be logged.
>>>> But even that is not correct.
>>>> Proposal: Remove the paragraph.
>>>> The intent was that an OC-OLR that contains unknown values should =
be discarded.  I agree that the wording needs to be changes as you =
suggested.  I don't agree with removing the paragraph.  Can you =
elaborate on why you think it is not correct when changed as you =
suggested?
>>>>=20
>>>> Regards,
>>>>=20
>>>> Steve
>>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>=20


From nobody Thu Dec 11 10:55:21 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7231A8937 for ; Thu, 11 Dec 2014 10:55:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtJzfyQ9uU6p for ; Thu, 11 Dec 2014 10:55:16 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12E7C1A876E for ; Thu, 11 Dec 2014 10:55:16 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBBItEdM021382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2014 12:55:15 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5489A506.1070700@usdonovans.com>
Date: Thu, 11 Dec 2014 12:55:14 -0600
X-Mao-Original-Outgoing-Id: 440016914.76284-90ff8c16389ca9079e937ea6cf13dec4
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <548701E1.3060502@usdonovans.com> <6A70A6FF-1A7B-4372-BD05-B96C7DE69F9F@nostrum.com> <5489A506.1070700@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/fIsiP_O3FND5RxJGVd2aMHlSfnc
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #16
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 18:55:20 -0000

> On Dec 11, 2014, at 8:07 AM, Steve Donovan  =
wrote:
>=20
> Ben,
>=20
> Diversion works for realm-routed requests in response to host reports.

The original language did not discriminate on report-type. But I see =
you've sent a text proposal that does, so I will reply there.

I still take issue with your assertion that diversion is not about =
server selection. I think for the context of this section, it is exactly =
about server selection.

>=20
> See my proposed wording sent in an early email.
>=20
> Steve
>=20
> On 12/10/14, 5:42 PM, Ben Campbell wrote:
>>> On Dec 9, 2014, at 8:06 AM, Steve Donovan  =
wrote:
>>>=20
>>> Ulrich,
>>>=20
>>> For your suggested change #16:
>>>=20
>>> Section 4.2.2, 5th and 6th paragraph:
>>> Existing text:
>>>    If the request is a host-routed request then the reacting node =
SHOULD
>>>    apply throttling abatement treatment to the request.
>>>      If the request is a realm-routed request then the reacting node
>>>    SHOULD apply diversion abatement treatment to the request.
>>>=20
>>> Comment: I don't think so. If the reacting node selects the server =
and
>>> then detects that the selected server is overloaded and then detects =
that
>>> the request does not survive (i.e. is subject to abatement), then =
the reacting
>>> node SHOULD apply diversion treatment (i.e. select an alternative =
server if possible).
>>> If the reacting node does not select the server (either a. because =
the server was
>>> already selected by a downstream node, or b. because the server will =
be selected
>>> by an upstream node) then there is no point in applying diversion =
and the reacting
>>> node SHOULD apply throttling of requests that do not survive.
>>>=20
>>> Proposal: replace the paragraphs with:
>>>    If the reacting node does not select the server then it SHOULD =
apply
>>>    throttling abatement to the request.
>>>=20
>>>    If the reacting node selects the server then it SHOULD apply =
diversion
>>>    abatement treatment (i.e. select an alternative server if =
possible) to
>>>    the request.
>>>=20
>>> Diversion is not selecting an alternative node to handle the =
request.  Diversion is selecting an alternative route to the selected =
node.
>> Hmm. Isn't that only true for the proposed Peer-Report type in the =
Agent draft?
>>=20
>>> =20
>>> Whether it is appropriate to select an alternative node for a =
request is an application decision that probably changes on a per =
command-code basis within the application.  Logic like this is outside =
the scope of the DOIC specification.
>> So how does it work for existing applications? But I agree in =
principle. I somehow missed that we had 2119 language around this. I =
think the choice to apply diversion vs throttling should be local =
policy. We don't need to state it normatively.
>>=20
>>> The text is correct based on the definition of diversion.
>> I'm not sure we have that definition right.
>>=20
>>> Regards,
>>>=20
>>> Steve
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>=20


From nobody Thu Dec 11 11:03:37 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49871ACF7F for ; Thu, 11 Dec 2014 11:03:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhFYP3iIkeTK for ; Thu, 11 Dec 2014 11:03:33 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FFA71ACF79 for ; Thu, 11 Dec 2014 11:03:32 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBBJ3UZn022129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2014 13:03:31 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <54884556.90108@usdonovans.com>
Date: Thu, 11 Dec 2014 13:03:30 -0600
X-Mao-Original-Outgoing-Id: 440017410.739983-07a15ea4f5fd33f53e6521badc7cf86e
Content-Transfer-Encoding: quoted-printable
Message-Id: <9B6C0FB1-B3D5-4050-B79D-E429A440CE79@nostrum.com>
References: <548701E1.3060502@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235234@DEMUMBX014.nsn-intra.net> <54884556.90108@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/f_Cegd0e3Y0jn3C6_VMANvYC86Q
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #16
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 19:03:36 -0000

> On Dec 10, 2014, at 7:06 AM, Steve Donovan  =
wrote:
>=20
> Ulrich,
>=20
> I agree with your assumptions below.  For the third one, the only time =
it is possible, at least from a DOIC perspective, to send to another =
host is if it is a realm-routed request.  I might also change the "not =
overloaded" to "less overloaded".
>=20
> I do think the statements can be improved to differentiate between =
behavior for host reports and realm reports.
>=20
> How about the following:
>    For OLRs of type host, if the request is a host-routed request then =
the reacting node SHOULD
>    apply throttling abatement treatment to the request.
>=20
>    For OLRs of type host, If the request is a realm-routed request =
then the reacting node
>    SHOULD apply diversion abatement treatment to the request.

Personally, I think that should be non-normative. Or if normative, no =
stronger than MAY. I agree it's a good choice, but I think we can leave =
it to the market to enforce.

I think there when we distinguish request-type, we need to consider =
_when_. For example, an agent may _receive_ a realm routed request but =
_send_ a host-routed request. And for a client, that may be even more =
subtle.

This really does seem like a case of server selection.

>=20
>    For OLRs of type realm, the reacting node SHOULD
>    apply throttling abatement treatment to the request, independent of =
the type (host-routed or=20
>    realm-routed) of request.

Again, I think this should not be normative. In this case this is pretty =
much a statement of fact--you simply cannot reasonably divert given the =
way that Diameter routing works.  I suppose there might be a case where =
a node has some magical knowledge that realm2 can handle anything that =
realm1 can, and could divert to a different realm (which we probably =
still don't want to forbid.)

>=20
>=20
> Regards,
>=20
> Steve
>=20
> On 12/9/14, 11:29 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Steve,
>> yes, then, maybe, the definition of Diversion is not correct?
>> What are other people's views?
>>=20
>> My assumption was:
>> If a host is overloaded, it does not help to direct traffic to that =
host via a different path.
>> If a realm is overloaded, it does not help to direct traffic to that =
realm via a different path.
>> If a host is overloaded, it helps to select an alternative (not =
overloaded) host (if possible) and direct traffic to that host.
>> If a realm is overloaded, there never is an alternative (not =
overloaded) realm to which traffic could be directed.
>>=20
>> With the current definition of Diversion, Diversion is no appropriate =
means to address host overload and is no appropriate means to address =
realm overload. It may be ok for agent overload only.
>>=20
>> Regards
>> Ulrich
>>=20
>> From: DiME [
>> mailto:dime-bounces@ietf.org
>> ] On Behalf Of ext Steve Donovan
>> Sent: Tuesday, December 09, 2014 3:06 PM
>> To:=20
>> dime@ietf.org
>>=20
>> Subject: [Dime] Ulrich's suggested change #16
>>=20
>> Ulrich,
>>=20
>> For your suggested change #16:
>> Section 4.2.2, 5th and 6th paragraph:
>> Existing text:
>>    If the request is a host-routed request then the reacting node =
SHOULD
>>    apply throttling abatement treatment to the request.
>> =20
>>    If the request is a realm-routed request then the reacting node
>>    SHOULD apply diversion abatement treatment to the request.
>>=20
>> Comment: I don't think so. If the reacting node selects the server =
and=20
>> then detects that the selected server is overloaded and then detects =
that=20
>> the request does not survive (i.e. is subject to abatement), then the =
reacting=20
>> node SHOULD apply diversion treatment (i.e. select an alternative =
server if possible).=20
>> If the reacting node does not select the server (either a. because =
the server was=20
>> already selected by a downstream node, or b. because the server will =
be selected=20
>> by an upstream node) then there is no point in applying diversion and =
the reacting=20
>> node SHOULD apply throttling of requests that do not survive.
>>=20
>> Proposal: replace the paragraphs with:
>>    If the reacting node does not select the server then it SHOULD =
apply
>>    throttling abatement to the request.
>>=20
>>    If the reacting node selects the server then it SHOULD apply =
diversion
>>    abatement treatment (i.e. select an alternative server if =
possible) to
>>    the request.
>> Diversion is not selecting an alternative node to handle the request. =
 Diversion is selecting an alternative route to the selected node. =20
>>=20
>> Whether it is appropriate to select an alternative node for a request =
is an application decision that probably changes on a per command-code =
basis within the application.  Logic like this is outside the scope of =
the DOIC specification.
>>=20
>> The text is correct based on the definition of diversion.
>>=20
>> Regards,
>>=20
>> Steve
>>=20
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Thu Dec 11 11:25:48 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105FC1A8979 for ; Thu, 11 Dec 2014 11:25:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QbNLy0DDmQl for ; Thu, 11 Dec 2014 11:25:44 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7D31A6FC6 for ; Thu, 11 Dec 2014 11:25:43 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62692 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Xz9Ml-0008LD-23; Thu, 11 Dec 2014 11:25:41 -0800
Message-ID: <5489EFAF.8010702@usdonovans.com>
Date: Thu, 11 Dec 2014 13:25:35 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Campbell 
References: <5486FE71.70205@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235215@DEMUMBX014.nsn-intra.net> <54884137.4050209@usdonovans.com> <5AB8BAC5-3CBD-432E-9631-74DF40795844@nostrum.com> <5489A498.5070203@usdonovans.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/AeCUYCEqFvI5BaL-jZeOm0vtgio
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #15
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 19:25:45 -0000

On 12/11/14, 12:51 PM, Ben Campbell wrote:
>> On Dec 11, 2014, at 8:05 AM, Steve Donovan  wrote:
>>
>> I thought this paragraph was covering unrecognized values for all AVPs.
> I agree that's what it covered. But I think we failed to cover the unrecognized AVP case. If we don't have anything to say beyond what 6733 says, then it might not be strictly necessary, but it might still be worth saying that "unrecognized sub-AVPs are treated as per RFC6733".
That is probably worth saying.
>
>>   Maybe it is better to remove the paragraph entirely and make sure that the definition of each AVP addresses what is done with unrecognized values.
> Possibly. There are AVPs where there's no such thing as an unrecognized value. There may be AVPs where the allowed values vary by algorithm. If we do take that route, we probably need language here that says unrecognized values are handled as described by the AVP definition or the algorithm.
Agreed.
>
>> Steve
>>
>> On 12/10/14, 5:26 PM, Ben Campbell wrote:
>>>> On Dec 10, 2014, at 6:48 AM, Steve Donovan  wrote:
>>>>
>>>> Ulrich,
>>>>
>>>> Actually, the wording you suggested wasn't quite right.  It should be:
>>>>
>>>>    When receiving an OC-OLR AVP with unknown values, the overload report
>>>>    SHOULD be silently discarded by reacting nodes and the event SHOULD
>>>>    be logged.
>>>>
>>>> It's not just about report type values but unknown values for any of the AVPs in the OLR.
>>>>
>>>> This seems like a good requirement to include in the specification to ensure common behavior in reacting nodes.  I don't feel strongly about this but I would like to hear other opinions.
>>> I think this is still not quite complete.
>>>
>>> If you receive a sub-AVP that you don't understand, then you should ignore that sub-avp, not the whole OC-OLR AVP.  (Unless of course the unknown AVP has the m-bit set.) If you receive a known sub-AVP, with a value you don't understand, the behavior should be AVP specific. For Report-Type, that means ignore the whole OLR.
>>>
>>> It's not clear to me whether the original text was about arbitrary avps, or Report-Type.
>>>
>>>> Steve
>>>>
>>>> On 12/9/14, 11:04 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>>> Hi Steve,
>>>>>
>>>>> I think it was pointed out by Ben that we do not specify behaviour of a node for cases where it detects that another node is breaking the rule.
>>>>> The rule is:
>>>>>     A reporting node MUST NOT send overload reports of a type that has
>>>>>     not been advertised as supported by the reacting node.
>>>>> See section 4.2.3.
>>>>>
>>>>> Regards
>>>>> Ulrich
>>>>>
>>>>>    From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>>>>> Sent: Tuesday, December 09, 2014 2:52 PM
>>>>> To: dime@ietf.org
>>>>> Subject: [Dime] Ulrich's suggested change #15
>>>>>
>>>>> Ulrich,
>>>>>
>>>>> For your suggested change #15:
>>>>> Section 4.2.1.3, 4th paragraph:
>>>>> Existing text:
>>>>>     When receiving an OC-OLR AVPs with unknown values, a reacting node
>>>>>     SHOULD be silently discarded by reacting nodes and the event SHOULD
>>>>>     be logged.
>>>>> Comment: text is confusing. Maybe the intention was to say:
>>>>>     When receiving an OC-OLR AVPs with an unsupported report type value, a reacting node
>>>>>     SHOULD silently discarded the OC-OLR AVP and the event SHOULD
>>>>>     be logged.
>>>>> But even that is not correct.
>>>>> Proposal: Remove the paragraph.
>>>>> The intent was that an OC-OLR that contains unknown values should be discarded.  I agree that the wording needs to be changes as you suggested.  I don't agree with removing the paragraph.  Can you elaborate on why you think it is not correct when changed as you suggested?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Steve
>>>>>
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Thu Dec 11 11:27:18 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD78E1A888F for ; Thu, 11 Dec 2014 11:27:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3ONm1yFwCLk for ; Thu, 11 Dec 2014 11:27:14 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6AB1A8727 for ; Thu, 11 Dec 2014 11:27:14 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62695 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Xz9OK-000AvP-77; Thu, 11 Dec 2014 11:27:13 -0800
Message-ID: <5489F010.3090601@usdonovans.com>
Date: Thu, 11 Dec 2014 13:27:12 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Campbell 
References: <548701E1.3060502@usdonovans.com> <6A70A6FF-1A7B-4372-BD05-B96C7DE69F9F@nostrum.com> <5489A506.1070700@usdonovans.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/h8r5YqJMUbMZOEH8ii8JqZ_S_kE
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #16
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 19:27:15 -0000

On 12/11/14, 12:55 PM, Ben Campbell wrote:
>> On Dec 11, 2014, at 8:07 AM, Steve Donovan  wrote:
>>
>> Ben,
>>
>> Diversion works for realm-routed requests in response to host reports.
> The original language did not discriminate on report-type. But I see you've sent a text proposal that does, so I will reply there.
>
> I still take issue with your assertion that diversion is not about server selection. I think for the context of this section, it is exactly about server selection.
Yes, it feeds into server selection.  It does not apply if server 
selection has already been done, either by a previous transaction or by 
a previous Diameter node.
>
>> See my proposed wording sent in an early email.
>>
>> Steve
>>
>> On 12/10/14, 5:42 PM, Ben Campbell wrote:
>>>> On Dec 9, 2014, at 8:06 AM, Steve Donovan  wrote:
>>>>
>>>> Ulrich,
>>>>
>>>> For your suggested change #16:
>>>>
>>>> Section 4.2.2, 5th and 6th paragraph:
>>>> Existing text:
>>>>     If the request is a host-routed request then the reacting node SHOULD
>>>>     apply throttling abatement treatment to the request.
>>>>       If the request is a realm-routed request then the reacting node
>>>>     SHOULD apply diversion abatement treatment to the request.
>>>>
>>>> Comment: I don't think so. If the reacting node selects the server and
>>>> then detects that the selected server is overloaded and then detects that
>>>> the request does not survive (i.e. is subject to abatement), then the reacting
>>>> node SHOULD apply diversion treatment (i.e. select an alternative server if possible).
>>>> If the reacting node does not select the server (either a. because the server was
>>>> already selected by a downstream node, or b. because the server will be selected
>>>> by an upstream node) then there is no point in applying diversion and the reacting
>>>> node SHOULD apply throttling of requests that do not survive.
>>>>
>>>> Proposal: replace the paragraphs with:
>>>>     If the reacting node does not select the server then it SHOULD apply
>>>>     throttling abatement to the request.
>>>>
>>>>     If the reacting node selects the server then it SHOULD apply diversion
>>>>     abatement treatment (i.e. select an alternative server if possible) to
>>>>     the request.
>>>>
>>>> Diversion is not selecting an alternative node to handle the request.  Diversion is selecting an alternative route to the selected node.
>>> Hmm. Isn't that only true for the proposed Peer-Report type in the Agent draft?
>>>
>>>>   
>>>> Whether it is appropriate to select an alternative node for a request is an application decision that probably changes on a per command-code basis within the application.  Logic like this is outside the scope of the DOIC specification.
>>> So how does it work for existing applications? But I agree in principle. I somehow missed that we had 2119 language around this. I think the choice to apply diversion vs throttling should be local policy. We don't need to state it normatively.
>>>
>>>> The text is correct based on the definition of diversion.
>>> I'm not sure we have that definition right.
>>>
>>>> Regards,
>>>>
>>>> Steve
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Thu Dec 11 11:36:46 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007BC1A6F02 for ; Thu, 11 Dec 2014 11:36:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66k2qd4mjjcU for ; Thu, 11 Dec 2014 11:36:42 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827181A1A9A for ; Thu, 11 Dec 2014 11:36:42 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62712 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Xz9XS-0009zx-6Q; Thu, 11 Dec 2014 11:36:41 -0800
Message-ID: <5489F246.5040801@usdonovans.com>
Date: Thu, 11 Dec 2014 13:36:38 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Campbell 
References: <548701E1.3060502@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235234@DEMUMBX014.nsn-intra.net> <54884556.90108@usdonovans.com> <9B6C0FB1-B3D5-4050-B79D-E429A440CE79@nostrum.com>
In-Reply-To: <9B6C0FB1-B3D5-4050-B79D-E429A440CE79@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/8aI32VVP4TK7M_R_pyYbaNA5tEg
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #16
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 19:36:44 -0000

On 12/11/14, 1:03 PM, Ben Campbell wrote:
>> On Dec 10, 2014, at 7:06 AM, Steve Donovan  wrote:
>>
>> Ulrich,
>>
>> I agree with your assumptions below.  For the third one, the only time it is possible, at least from a DOIC perspective, to send to another host is if it is a realm-routed request.  I might also change the "not overloaded" to "less overloaded".
>>
>> I do think the statements can be improved to differentiate between behavior for host reports and realm reports.
>>
>> How about the following:
>>     For OLRs of type host, if the request is a host-routed request then the reacting node SHOULD
>>     apply throttling abatement treatment to the request.
>>
>>     For OLRs of type host, If the request is a realm-routed request then the reacting node
>>     SHOULD apply diversion abatement treatment to the request.
> Personally, I think that should be non-normative. Or if normative, no stronger than MAY. I agree it's a good choice, but I think we can leave it to the market to enforce.
If we make it non normative then we probably need an additional 
statement along the lines of "the reacting node MUST attempt to reduce 
traffic by the amount requested in the OLR" if we don't already have it 
somewhere else in the document.
>
> I think there when we distinguish request-type, we need to consider _when_. For example, an agent may _receive_ a realm routed request but _send_ a host-routed request. And for a client, that may be even more subtle.
>
> This really does seem like a case of server selection.
I don't think it's that subtle.  If server selection hasn't already 
happened for a request and that request is selected for abatement and 
the request would have otherwise been routed to an overloaded host then 
the request should/may be diverted to another server.

Server selection could have happened as a result of a previous 
transaction specifying the host for subsequent transactions or by the 
presence of the Destination-Host in the message when it arrives at an 
agent.  It could have also already happened as a result of configuration.
>
>>     For OLRs of type realm, the reacting node SHOULD
>>     apply throttling abatement treatment to the request, independent of the type (host-routed or
>>     realm-routed) of request.
> Again, I think this should not be normative. In this case this is pretty much a statement of fact--you simply cannot reasonably divert given the way that Diameter routing works.  I suppose there might be a case where a node has some magical knowledge that realm2 can handle anything that realm1 can, and could divert to a different realm (which we probably still don't want to forbid.)
>
>>
>> Regards,
>>
>> Steve
>>
>> On 12/9/14, 11:29 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>> Steve,
>>> yes, then, maybe, the definition of Diversion is not correct?
>>> What are other people's views?
>>>
>>> My assumption was:
>>> If a host is overloaded, it does not help to direct traffic to that host via a different path.
>>> If a realm is overloaded, it does not help to direct traffic to that realm via a different path.
>>> If a host is overloaded, it helps to select an alternative (not overloaded) host (if possible) and direct traffic to that host.
>>> If a realm is overloaded, there never is an alternative (not overloaded) realm to which traffic could be directed.
>>>
>>> With the current definition of Diversion, Diversion is no appropriate means to address host overload and is no appropriate means to address realm overload. It may be ok for agent overload only.
>>>
>>> Regards
>>> Ulrich
>>>
>>> From: DiME [
>>> mailto:dime-bounces@ietf.org
>>> ] On Behalf Of ext Steve Donovan
>>> Sent: Tuesday, December 09, 2014 3:06 PM
>>> To:
>>> dime@ietf.org
>>>
>>> Subject: [Dime] Ulrich's suggested change #16
>>>
>>> Ulrich,
>>>
>>> For your suggested change #16:
>>> Section 4.2.2, 5th and 6th paragraph:
>>> Existing text:
>>>     If the request is a host-routed request then the reacting node SHOULD
>>>     apply throttling abatement treatment to the request.
>>>   
>>>     If the request is a realm-routed request then the reacting node
>>>     SHOULD apply diversion abatement treatment to the request.
>>>
>>> Comment: I don't think so. If the reacting node selects the server and
>>> then detects that the selected server is overloaded and then detects that
>>> the request does not survive (i.e. is subject to abatement), then the reacting
>>> node SHOULD apply diversion treatment (i.e. select an alternative server if possible).
>>> If the reacting node does not select the server (either a. because the server was
>>> already selected by a downstream node, or b. because the server will be selected
>>> by an upstream node) then there is no point in applying diversion and the reacting
>>> node SHOULD apply throttling of requests that do not survive.
>>>
>>> Proposal: replace the paragraphs with:
>>>     If the reacting node does not select the server then it SHOULD apply
>>>     throttling abatement to the request.
>>>
>>>     If the reacting node selects the server then it SHOULD apply diversion
>>>     abatement treatment (i.e. select an alternative server if possible) to
>>>     the request.
>>> Diversion is not selecting an alternative node to handle the request.  Diversion is selecting an alternative route to the selected node.
>>>
>>> Whether it is appropriate to select an alternative node for a request is an application decision that probably changes on a per command-code basis within the application.  Logic like this is outside the scope of the DOIC specification.
>>>
>>> The text is correct based on the definition of diversion.
>>>
>>> Regards,
>>>
>>> Steve
>>>
>>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Thu Dec 11 11:45:43 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31911A89F1 for ; Thu, 11 Dec 2014 11:45:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NZYuM8zv9wS for ; Thu, 11 Dec 2014 11:45:38 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D7951A89F9 for ; Thu, 11 Dec 2014 11:45:30 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBBJjSn5025950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2014 13:45:29 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5489F246.5040801@usdonovans.com>
Date: Thu, 11 Dec 2014 13:45:28 -0600
X-Mao-Original-Outgoing-Id: 440019928.700097-10fe316aaa98a15fbcc61a54d7940af7
Content-Transfer-Encoding: quoted-printable
Message-Id: <8D4FC2F7-30F8-41AF-9F19-209BB48FCB9D@nostrum.com>
References: <548701E1.3060502@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235234@DEMUMBX014.nsn-intra.net> <54884556.90108@usdonovans.com> <9B6C0FB1-B3D5-4050-B79D-E429A440CE79@nostrum.com> <5489F246.5040801@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/up-_QZ5Rfg7mhdnP2y2K3uCIsfc
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #16
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 19:45:41 -0000

> On Dec 11, 2014, at 1:36 PM, Steve Donovan  =
wrote:
>=20
>=20
> On 12/11/14, 1:03 PM, Ben Campbell wrote:
>>> On Dec 10, 2014, at 7:06 AM, Steve Donovan =
 wrote:
>>>=20
>>> Ulrich,
>>>=20
>>> I agree with your assumptions below.  For the third one, the only =
time it is possible, at least from a DOIC perspective, to send to =
another host is if it is a realm-routed request.  I might also change =
the "not overloaded" to "less overloaded".
>>>=20
>>> I do think the statements can be improved to differentiate between =
behavior for host reports and realm reports.
>>>=20
>>> How about the following:
>>>    For OLRs of type host, if the request is a host-routed request =
then the reacting node SHOULD
>>>    apply throttling abatement treatment to the request.
>>>=20
>>>    For OLRs of type host, If the request is a realm-routed request =
then the reacting node
>>>    SHOULD apply diversion abatement treatment to the request.
>> Personally, I think that should be non-normative. Or if normative, no =
stronger than MAY. I agree it's a good choice, but I think we can leave =
it to the market to enforce.
> If we make it non normative then we probably need an additional =
statement along the lines of "the reacting node MUST attempt to reduce =
traffic by the amount requested in the OLR" if we don't already have it =
somewhere else in the document.

Agreed

>>=20
>> I think there when we distinguish request-type, we need to consider =
_when_. For example, an agent may _receive_ a realm routed request but =
_send_ a host-routed request. And for a client, that may be even more =
subtle.
>>=20
>> This really does seem like a case of server selection.
> I don't think it's that subtle.  If server selection hasn't already =
happened for a request and that request is selected for abatement and =
the request would have otherwise been routed to an overloaded host then =
the request should/may be diverted to another server.
>=20
> Server selection could have happened as a result of a previous =
transaction specifying the host for subsequent transactions or by the =
presence of the Destination-Host in the message when it arrives at an =
agent.  It could have also already happened as a result of =
configuration.

In the case of a client, the decision on whether to divert vs just not =
send a request may be heavily influenced by the client application.  =
(Not necessarily the _Diameter_ application.)  In the case of either, a =
node might have local knowledge that a 2nd server can handle everything =
the first server can handle. Even if a downstream node performed server =
selection, a node with such knowledge might override it. We don't =
necessarily need to talk about that sort of thing, but we should avoid =
language that forbids it.


>>=20
>>>    For OLRs of type realm, the reacting node SHOULD
>>>    apply throttling abatement treatment to the request, independent =
of the type (host-routed or
>>>    realm-routed) of request.
>> Again, I think this should not be normative. In this case this is =
pretty much a statement of fact--you simply cannot reasonably divert =
given the way that Diameter routing works. I suppose there might be a =
case where a node has some magical knowledge that realm2 can handle =
anything that realm1 can, and could divert to a different realm (which =
we probably still don't want to forbid.)
>>=20
>>>=20
>>> Regards,
>>>=20
>>> Steve
>>>=20
>>> On 12/9/14, 11:29 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>> Steve,
>>>> yes, then, maybe, the definition of Diversion is not correct?
>>>> What are other people's views?
>>>>=20
>>>> My assumption was:
>>>> If a host is overloaded, it does not help to direct traffic to that =
host via a different path.
>>>> If a realm is overloaded, it does not help to direct traffic to =
that realm via a different path.
>>>> If a host is overloaded, it helps to select an alternative (not =
overloaded) host (if possible) and direct traffic to that host.
>>>> If a realm is overloaded, there never is an alternative (not =
overloaded) realm to which traffic could be directed.
>>>>=20
>>>> With the current definition of Diversion, Diversion is no =
appropriate means to address host overload and is no appropriate means =
to address realm overload. It may be ok for agent overload only.
>>>>=20
>>>> Regards
>>>> Ulrich
>>>>=20
>>>> From: DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] On Behalf Of ext Steve Donovan
>>>> Sent: Tuesday, December 09, 2014 3:06 PM
>>>> To:
>>>> dime@ietf.org
>>>>=20
>>>> Subject: [Dime] Ulrich's suggested change #16
>>>>=20
>>>> Ulrich,
>>>>=20
>>>> For your suggested change #16:
>>>> Section 4.2.2, 5th and 6th paragraph:
>>>> Existing text:
>>>>    If the request is a host-routed request then the reacting node =
SHOULD
>>>>    apply throttling abatement treatment to the request.
>>>>      If the request is a realm-routed request then the reacting =
node
>>>>    SHOULD apply diversion abatement treatment to the request.
>>>>=20
>>>> Comment: I don't think so. If the reacting node selects the server =
and
>>>> then detects that the selected server is overloaded and then =
detects that
>>>> the request does not survive (i.e. is subject to abatement), then =
the reacting
>>>> node SHOULD apply diversion treatment (i.e. select an alternative =
server if possible).
>>>> If the reacting node does not select the server (either a. because =
the server was
>>>> already selected by a downstream node, or b. because the server =
will be selected
>>>> by an upstream node) then there is no point in applying diversion =
and the reacting
>>>> node SHOULD apply throttling of requests that do not survive.
>>>>=20
>>>> Proposal: replace the paragraphs with:
>>>>    If the reacting node does not select the server then it SHOULD =
apply
>>>>    throttling abatement to the request.
>>>>=20
>>>>    If the reacting node selects the server then it SHOULD apply =
diversion
>>>>    abatement treatment (i.e. select an alternative server if =
possible) to
>>>>    the request.
>>>> Diversion is not selecting an alternative node to handle the =
request.  Diversion is selecting an alternative route to the selected =
node.
>>>>=20
>>>> Whether it is appropriate to select an alternative node for a =
request is an application decision that probably changes on a per =
command-code basis within the application. Logic like this is outside =
the scope of the DOIC specification.
>>>>=20
>>>> The text is correct based on the definition of diversion.
>>>>=20
>>>> Regards,
>>>>=20
>>>> Steve
>>>>=20
>>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime


From nobody Thu Dec 11 15:33:33 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F92E1A8A52 for ; Thu, 11 Dec 2014 15:33:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66SdiZDxdD-X for ; Thu, 11 Dec 2014 15:33:30 -0800 (PST)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1EAC1A1A5E for ; Thu, 11 Dec 2014 15:33:29 -0800 (PST)
Received: by mail-lb0-f177.google.com with SMTP id b6so4841858lbj.8 for ; Thu, 11 Dec 2014 15:33:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=ejjlSA6StVPsH47v2n3utfQY0/NYODHELMtp5KtWli4=; b=Mt1TmSwhoBY+jzdDTL3Ub/ldM1J69HrQDBT51iTbhil1eyibcfW046Z7su00B8x7eB bWWB4meQXwVLC18gRl/wTyEd4kBo3zLJNxmLW3xXbj+95It36Vwsl5gpPvBi/re2Cms6 hQm0JJ3TPC6+RY9mL8dZ5jA4v/7W4QRbHGzSkkdgY5Goaspp1VLOdXoXUDhHyzHGF3HT E+8aiYltLn5AxleEzhDyHpEm2BiPCrokIaOylu0Zf8UdQfhRWSDvF9WkhcxloOKjUCBN /Y8dKE+QyZaU4kDSbhOQJtME89pDOGUoboZHi2EfEEMFC5UYdkELhwl4aRXcZyfGJcLZ ibLg==
X-Received: by 10.112.205.65 with SMTP id le1mr12482297lbc.54.1418340808085; Thu, 11 Dec 2014 15:33:28 -0800 (PST)
Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPSA id zc5sm762521lbb.49.2014.12.11.15.33.26 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Dec 2014 15:33:27 -0800 (PST)
From: Jouni 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 12 Dec 2014 01:33:25 +0200
Message-Id: 
To: "dime@ietf.org list" 
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/8nJvJ_D_bI3CxDNogBsuW9iim5g
Subject: [Dime] early IANA assignments for DOIC
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Dec 2014 23:33:31 -0000

Folks,

During the last meeting we had discussion on early IANA assignment of =
AVP codes for the DOIC. The actual process for that is now BCPed in =
RFC7120. So far we have one request, which hardly meets the criteria of =
the "sufficient interest in the community". Are there others (Steve is =
noted in the Honolulu meeting minutes) who would like to see the IANA =
process started already ahead of time before the I-D leaves the WG or =
around that time?.

- Jouni & Lionel=


From nobody Fri Dec 12 00:04:28 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52E31AC40E for ; Fri, 12 Dec 2014 00:04:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8RObzS8_EAv for ; Fri, 12 Dec 2014 00:04:23 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC9821A6EED for ; Fri, 12 Dec 2014 00:04:22 -0800 (PST)
X-AuditID: c1b4fb25-f791c6d00000617b-a2-548aa184c8b4
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9E.52.24955.481AA845; Fri, 12 Dec 2014 09:04:20 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.41]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 09:04:20 +0100
From: Maria Cruz Bartolome 
To: Ben Campbell 
Thread-Topic: [Dime] Updates to DOIC -05
Thread-Index: AQHP96zTVLWd5veGrkqAoFDKpocx+ZxXdZWAgAKB9QCAABTjgIABToGAgABXjYCAAImqAIAAtOqAgAHz+gCAAFg3AIAFNTcAgAARHgCABzpwAIAFs+cAgABIhYCACwbhAIABEZ9ggAATtICAAFSrgIAKq7MggAC/3gCAAi4MMA==
Date: Fri, 12 Dec 2014 08:04:19 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209880865@ESESSMB101.ericsson.se>
References: <545792B6.8030502@usdonovans.com> <24888_1415758364_5462C21C_24888_19283_1_6c33c20a-bfd3-4a2e-94ea-a49704889510@PEXCVZYH02.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D900066815228DC9@DEMUMBX014.nsn-intra.net> <5464FD42.8080709@usdonovans.com> <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, > <087A34937E64E74E848732CFF8354B9209863A54@ESESSMB101.ericsson.se> <24987_1416213505_5469B401_24987_4151_1_judb1lo2cnj5m4v6mdt5aec1.1416213483721@email.android.com>  <54748CEA.3020705@usdonovans.com> <19072_1416939968_5474C9C0_19072_1519_1_6B7134B31289DC4FAF731D844122B36E941639@PEXCVZYM13.corporate.adroot.infra.ftgroup> <547E09C0.5080305@usdonovans.com>   <547F46D5.7060800@usdonovans.! com> <087A34937E64E74E848732CFF8354B920987F790@ESESSMB101.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGfG3RrdlYVeIQX+7qcX8ztPsFnN7V7BZ bDq/jsXi9vZMiw1NPA6sHq3P9rJ6LFnyk8lj1s4nLB4tz06yeax628cawBrFZZOSmpNZllqk b5fAlbF2x2Hmgr8JFecXfmBsYDzh28XIySEhYCLx7s5OZghbTOLCvfVsXYxcHEICRxglNj86 xAzhLGaU2HV3JStIFZuAncSl0y+YQGwRASWJ581bWUCKmAXuMEo8/HuBDSQhLKAusXznL1aI Ig2JviOrmSHsXYwSr/piuhg5OFgEVCX2zw0DCfMK+Eqcbutmh1j2jUPiUvMXRpAaTgF7iYM7 zUFqGIGu+35qDdheZgFxiVtP5jNBXC0gsWTPeagPRCVePv7HCtIqIaAosbxfDqJcT+LG1Cls ELa2xLKFr5kh1gpKnJz5hGUCo9gsJFNnIWmZhaRlFpKWBYwsqxhFi1OLk3LTjYz1Uosyk4uL 8/P08lJLNjEC4+7glt+qOxgvv3E8xCjAwajEw1swqStEiDWxrLgy9xCjNAeLkjjvwnPzgoUE 0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwdgbN37FdgM/M4IiLvu3SmvrPO8UT3TxP5248yx7g keNeFDv/YOuuEk23+u28zRdlXa/aMRSseFBY9aCeffGBDKOgVcpO71XeXTgheVVJ2W+JBRN/ 9voFPsH/ivYUle9YJ5F3egZTHa/yft4EqT+hbrUL7q2U9zp0u3/vDot3tX9ZTrl673NSYinO SDTUYi4qTgQA8uKcHZwCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/bWl6PHL6TmyhVfVKQoU5_S7gc0c
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Updates to DOIC -05
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Dec 2014 08:04:27 -0000

2119 language is not required in my opinion, as long as the message is tran=
smitted.
Cheers
/MCruz

-----Original Message-----
From: Ben Campbell [mailto:ben@nostrum.com]=20
Sent: jueves, 11 de diciembre de 2014 0:46
To: Maria Cruz Bartolome
Cc: Steve Donovan; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); lionel.morand@oran=
ge.com; dime@ietf.org
Subject: Re: [Dime] Updates to DOIC -05


> On Dec 10, 2014, at 9:09 AM, Maria Cruz Bartolome  wrote:
>=20
> Dear all,
> =20
> I have the following proposal, for first paragraph
> Now:
> Therefore, before
>    applying local message throttling, a reporting node needs to check if
>    these messages match existing OCS entries,
> =20
> Proposal
> Therefore, before
>    applying local message throttling, a reporting node MAY check if
>    these messages match existing OCS entries,
> =20
> I think the reporting node may or not check whether the received messages=
 match a "delegated" active OCS. This is a processing consuming task that c=
ould be avoided if the reporting node uses different criteria to choose mes=
sages to drop/reject. This is up to  implementation.

I am okay with it being up to the implementation. I think the point of the =
warning is to let implementers know they need to consider this.=20

But I wonder why you want to add 2119 language when it didn't have it befor=
e?


> =20
> Best regards
> /MCruz
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
> Sent: mi=E9rcoles, 03 de diciembre de 2014 18:22
> To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); lionel.morand@orange.com;=20
> Ben Campbell
> Cc: dime@ietf.org
> Subject: Re: [Dime] Updates to DOIC -05
> =20
> I have attempted to address both Lionel's and Jean-Jacques' suggestions w=
ith the following text:
>=20
>    When a reporting node sends an OLR, it effectively delegates any
>    necessary throttling to downstream nodes.  If the reporting node also
>    locally throttles the same set of messages, the overall number of
>    throttled requests may be higher than intended.  Therefore, before
>    applying local message throttling, a reporting node needs to check if
>    these messages match existing OCS entries, indicating that these
>    messages have survived throttling applied by downstream nodes that
>    have received the related OLR.
> =20
>    However, even if the set of messages match existing OCS entries, the
>    reporting node can still apply other abatement methods such as
>    diversion.  The reporting node might also need to throttle requests
>    for reasons other than overload.  For example, an agent or server
>    might have a configured rate limit for each client, and throttle
>    requests that exceed that limit, even if such requests had already
>    been candidates for throttling by downstream nodes.  The reporting
>    node also has the option to send new OLRs requesting greater
>    reductions in traffic, reducing the need for local throttling.
>=20
> Steve
>=20
> On 12/3/14, 6:19 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> Dear all
> =20
> To continue on my remark , I would complement the Steve's text with " can=
 update the reduction of traffic it requires from the reacting nodes(s) by =
sending new overload reports" as hereafter:   =20
> =20
>    Therefore, if a
>    reporting node needs to apply local throttling on a set of messages
>    that match existing OCS entries, it needs to consider
>    the impact of throttling by downstream nodes and can update the reduct=
ion of traffic it requires from the reacting nodes(s) by sending new overlo=
ad reports.=20
> =20
> Best regards
> =20
> JJacques
> =20
> =20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN,=20
> JEAN-JACQUES (JEAN-JACQUES) Envoy=E9 : mercredi 3 d=E9cembre 2014 11:29 =
=C0=20
> : Steve Donovan; lionel.morand@orange.com; Ben Campbell Cc :=20
> dime@ietf.org Objet : Re: [Dime] Updates to DOIC -05
> =20
> Dear all
> =20
> I am not against the new proposed texts from Steve or Ben to clarify this=
 topic.
> =20
> My point is that, when  the reporting node has sent an OLR requiring  a t=
raffic reduction , there is first a reaction time before receiving reduced =
traffic, and second even if the traffic has been reduced, it can still exce=
ed the capacity of the reporting node  that has no other choice than to thr=
ottle the received reduced traffic (if no diversion). This can happen when =
the traffic at the source (reacting node) before throttling is increasing q=
uickly, so the traffic reduced  according to the received OLR may  remain t=
oo high .  Then, if the reporting node has nevertheless to do some throttle=
, it will certainly react by new OLRs requiring a higher traffic reduction =
from the reacting nodes. This is a dynamic process, where the reporting nod=
e adjust the  traffic  reduction it requires according to what it receives =
.
> =20
> As Ben  I also think this is a guidance , and I think it is good to bring=
 some guidance.
> =20
> Best regards
> =20
> JJacques
> =20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan=20
> Envoy=E9 : mardi 2 d=E9cembre 2014 19:50 =C0 : lionel.morand@orange.com; =
Ben=20
> Campbell Cc : dime@ietf.org Objet : Re: [Dime] Updates to DOIC -05
> =20
> Lionel,
>=20
> The two paragraphs together now say the following:
>=20
>    When a reporting node sends an OLR, it effectively delegates any
>    necessary throttling to downstream nodes.  If the reporting node also
>    locally throttles the same set of messages, the overall number of
>    throttled request may be higher than intended.  Therefore, if a
>    reporting node needs to apply local throttling on a set of messages
>    that match or overlap with existing OCS entries, it needs to consider
>    the impact of throttling by downstream nodes.
> =20
>    However, when the reporting node sends an OLR downstream, it might
>    still need to apply other abatement methods such as diversion.  The
>    reporting node might also need to throttle requests for reasons other
>    than overload.  For example, an agent or server might have a
>    configured rate limit for each client, and throttle requests that
>    exceed that limit, even if such requests had already been candidates
>    for throttling by downstream nodes.
> Do you see the need for further clarification?
>=20
> Steve
>=20
> On 11/25/14, 12:26 PM, lionel.morand@orange.com wrote:
> I'm OK with the idea of the text proposed by Ben.
> I would just make clear that throttling is applicable to the fact of send=
ing/forwarding requests (cf. definition). A reporting node may apply local =
throttling if it is an agent. But if it is a server, it can either drop the=
 exceeded number of requests (no response sent to the downstream) or send a=
 specific DIAMETER-TOO-BUSY response. I think that this clarification is so=
mehow missing in the document.
> =20
> Regards,
> =20
> Lionel
> =20
> -----Message d'origine-----
> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi 25=
=20
> novembre 2014 15:07 =C0 : Ben Campbell; MORAND Lionel IMT/OLN Cc :=20
> Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; Maria Cruz Bartolome=20
> Objet : Re: [Dime] Updates to DOIC -05
> =20
> I'm ok with Ben's wording and will make the change unless I hear objectio=
ns on the list.
> =20
> Steve
> =20
> On 11/21/14, 5:01 PM, Ben Campbell wrote:
> On reflection, I think there might be a subtlety here. The resulting offe=
red-load may still exceed the reporting node's current capacity. This can b=
e true even if it's sent an OLR (and thus has related OCS). As mentioned in=
 the surrounding node needs to still be able to protect itself, possibly by=
 throttling. Therefore, I propose the sentence take the form of non-normati=
ve guidance. For example:
> =20
> "When a reporting node sends an OLR, it effectively delegates any necessa=
ry throttling to downstream nodes.  If the reporting node also locally thro=
ttles the same set of messages, the overall number of throttled request may=
 be higher than intended. Therefore, if a reporting node needs to apply loc=
al throttling on a set of messages that match or overlap with existing OCS =
entries, it needs to consider the impact of throttling by downstream nodes.=
"
> =20
>  =20
> On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com wrote:
> =20
> I can live with the text proposed by Ulrich. But what is wrong with:
> =20
> " Therefore, the reporting node SHOULD NOT apply throttling to the set of=
 messages to which an active OCS applies." ?
> =20
> Envoy=E9 depuis mon Sony Xperia SP d'Orange
> =20
> ---- Maria Cruz Bartolome a =E9crit ----
> =20
> =20
> Section 4.2.3, 13th paragraph, 2nd sentence:
> Existing text: Therefore, the reporting node SHOULD NOT apply throttling =
to the set of messages to which the OLR applies.
> Proposed text: Therefore, the reporting node SHOULD NOT apply throttling =
to the set of messages to which the sent OLR applies.
> =20
> [LM] I would say that the reporting node will not remember the previously=
 sent OLR, but will take care that there is an active OCS.
> SRD> I'm ok with Ulrich's change.
> =20
> [LM] and this is incorrect but not fundamental. The reporting node does n=
ot have to "remember" a previously sent OLR. What it will do is to refer to=
 existing OCS to know that throttling should not be applied. An OCS is a co=
nsequence of an sent OLR but it is not an OLR itself. But not fundamental h=
ere.
> =20
> [MCruz] I am ok with Ulrich's change. It does not mean that the reporting=
 node needs to "remember" a previously sent OLR, though. The change only pr=
oposes to "identify" which OLR we refer to.
> =20
> Best regards
> /MCruz
> =20
> =20
> _____________________________________________________________________
> ____________________________________________________
> =20
> Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
> =20
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =20
> =20
> ______________________________________________________________________
> ___________________________________________________
> =20
> Ce message et ses pieces jointes peuvent contenir des informations=20
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20
> exploites ou copies sans autorisation. Si vous avez recu ce message=20
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion, Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
> =20
> This message and its attachments may contain confidential or=20
> privileged information that may be protected by law; they should not be d=
istributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
> =20
> =20
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Dec 12 00:24:27 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B164A1A88CA for ; Fri, 12 Dec 2014 00:24:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YInZVn5sm8tf for ; Fri, 12 Dec 2014 00:24:21 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2B0B1A0058 for ; Fri, 12 Dec 2014 00:24:20 -0800 (PST)
X-AuditID: c1b4fb2d-f79fc6d000001087-2b-548aa6337799
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id EA.AA.04231.336AA845; Fri, 12 Dec 2014 09:24:19 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.41]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 09:24:18 +0100
From: Maria Cruz Bartolome 
To: Ben Campbell 
Thread-Topic: [Dime] Updated DOIC Requirements Analysis
Thread-Index: AQHQCFYt6tScBxBsq0iC3L6bres0LpyIv54AgADMHwCAAihrkA==
Date: Fri, 12 Dec 2014 08:24:17 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92098808EC@ESESSMB101.ericsson.se>
References: <46C8B155-A8B0-41F6-A8A5-6F21D61ADE9E@nostrum.com> <087A34937E64E74E848732CFF8354B920987F783@ESESSMB101.ericsson.se> <767BF9E5-A72B-44B5-A324-A0CF74F70A69@nostrum.com>
In-Reply-To: <767BF9E5-A72B-44B5-A324-A0CF74F70A69@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvja7xsq4Qg4s3hC3md55mt5jbu4LN gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4MpYMXsac8Evh4ptqxqZGhiX2HcxcnBICJhI TL/I1MXICWSKSVy4t56ti5GLQ0jgCKPE495J7BDOYkaJpsYWdpAqNgE7iUunX4B1iAgoSTxv 3soCYjMLaEhc2tLMCGILC5hJdM3awQZRYy4xdcFmZgjbSWLB0qdgcRYBVYmN+yaBzeQV8JV4 s7iHFcQWEtjOKPHyuSqIzSlgL3F/52mwekag676fWsMEsUtc4taT+VBXC0gs2XOeGcIWlXj5 +B8rxGOKEsv75UBMZgFNifW79CE6FSWmdD+E2ioocXLmE5YJjGKzkAydhdAxC0nHLCQdCxhZ VjGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIERs7BLb91dzCufu14iFGAg1GJh7dgUleIEGti WXFl7iFGaQ4WJXHeRefmBQsJpCeWpGanphakFsUXleakFh9iZOLglGpg5Ptf9XjrkzORdy+d 8Z8uffX+3n8ON8u5L6VXnp739CHbEfsf0mHpRWuf6rxIm7pp/nNW3ycqOStrVKdcFo19uPDn DnuNraqTAo5PP5GovCiG76l4xbkvrP5+Wftm5fxRepIR7fN7vWzYH4n7JZtPBK2Y9eu/yQPL jyyNvxnmH5yzv29Gnolwk78SS3FGoqEWc1FxIgAYkMr4fQIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9Ubzj4t8CqMV09Gshwc-6aMC4Ec
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] Updated DOIC Requirements Analysis
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Dec 2014 08:24:23 -0000

SGVsbG8gQmVuLA0KDQpTZWUgY29tbWVudHMgYmVsb3cNClRoYW5rcw0KL01DcnV6DQoNCj4gIA0K
PiBDLjIuICBEZXRlY3Rpb24gb2Ygbm9uLXN1cHBvcnRpbmcgSW50ZXJtZWRpYXJpZXMNCj4gIA0K
PiAgICBUaGUgRE9JQyBtZWNoYW5pc20gYXMgY3VycmVudGx5IGRlZmluZWQgZG9lcyBub3QgYWxs
b3cgc3VwcG9ydGluZw0KPiAgICBub2RlcyB0byBhdXRvbWF0aWNhbGx5IGRldGVybWluZSB3aGV0
aGVyIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBvciBPQy0NCj4gICAgT0xSIEFWUHMgYXJlIG9yaWdp
bmF0ZWQgYnkgYSBwZWVyIG5vZGUsIG9yIGJ5IGEgbm9uLXBlZXIgbm9kZSBhbmQNCj4gICAgc2Vu
dCBhY3Jvc3MgYSBub24tc3VwcG9ydGluZyBwZWVyLiAgVGhpcyBtYWtlcyBpdCBpbXBvc3NpYmxl
IHRvDQo+ICAgIGRldGVjdCB0aGUgcHJlc2VuY2Ugb2Ygbm9uLXN1cHBvcnRpbmcgbm9kZXMgYmV0
d2VlbiBzdXBwb3J0aW5nIG5vZGVzLA0KPiAgICBleGNlcHQgYnkgY29uZmlndXJhdGlvbi4gIFRo
ZSB3b3JraW5nIGdyb3VwIGRldGVybWluZWQgdGhhdCBzdWNoIGENCj4gICAgY29uZmlndXJhdGlv
biByZXF1aXJlbWVudCBpcyBhY2NlcHRhYmxlLg0KPiAgDQo+ICAgIFRoaXMgbGltaXRzIGZ1bGwg
Y29tcGxpYW5jZSB3aXRoIGNlcnRhaW4gcmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gdGhlDQo+ICAg
IGxpbWl0YXRpb24gb2YgbmV3IGNvbmZpZ3VyYXRpb24sIGRlcGxveW1lbnQgaW4gZW52aXJvbm1l
bnRzIHdpdGgNCj4gICAgbWl4ZWQgc3VwcG9ydCwgb3BlcmF0aW5nIGFjcm9zcyBub24tc3VwcG9y
dGluZyBhZ2VudHMsIGFuZA0KPiAgICBhdXRob3JpemF0aW9uLg0KPiBbTUNydXpdIEkgdGhpbmsg
dGhpcyBwYXJhZ3JhcGggc2hvdWxkIHN0YXRlIHdoYXQgYXJlIHRoZSBsaW1pdGF0aW9ucyANCj4g
KGdlbmVyYWxseSwgbGlrZSB5b3UgZGlkIGZvciByZXN0IG9mIHRoZW0pIE1vcmV2ZXIsIHNpbmNl
IGRldGFpbGVkIGRlc2NyaXB0aW9ucyB3aWxsIGJlIGRlbGV0ZWQuDQo+ICANCg0KVGhlIGxpbWl0
YXRpb25zIGFyZSBkaXNjdXNzZWQgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gc2VjdGlv
bi4gQmFzaWNhbGx5IGlmIGEgbm9kZSBleHBlY3RzIGFuIGFnZW50IHRvIGVuZm9yY2UgYW55IERP
SUMgcmVsYXRlZCBwb2xpY3kgKGUuZy4gbWFraW5nIHN1cmUgRE9JQyBhdnBzIGRvIG5vdCBsZWFr
IHRvIHVuYXV0aG9yaXplZCBub2RlcyksIGl0IGhhcyB0byBrbm93IHRoYXQgdGhlIGFnZW50IGl0
c2VsZiBzdXBwb3J0cyBET0lDLiBSaWdodCBub3cgaXQgY2FuIG9ubHkga25vdyB0aGF0IGJ5IGhh
dmluZyBhbiBhZG1pbmlzdHJhdG9yIHRlbGwgaXQgdGhhdCAodmlvbGF0aW5nIHRoZSBsaW1pdGF0
aW9uIG9uIG5ldyBjb25maWd1cmF0aW9uKSwgYnkga25vd2luZyB0aGF0IGFsbCBhZ2VudHMgaW4g
dGhlIG5ldHdvcmsgc3VwcG9ydCBET0lDICh2aW9sYXRpbmcgdGhlIG1peGVkIHN1cHBvcnQgYW5k
IG5vbi1zdXBwb3J0aW5nIGFnZW50IHJlcXVpcmVtZW50cy4pDQpbTUNydXpdIFBsZWFzZSwgaW5j
bHVkZSB0ZXh0IGFjY29yZGluZ2x5IHRoZW4uIFRoZSB0ZXh0IG5vdyAiY2VydGFpbiByZXF1aXJl
bWVudHMgcmVsYXRlZCB0byIgZG9lcyBub3QgcHJvdmlkZSBhbiBpbmZvcm1hdGlvbiB0aGF0IGFu
eW9uZSBjb3VsZCB0cmFjZSBlYXNpbHkuDQoNCj4gIA0KPiAgDQo+ICANCj4gICAgUkVRIDY6ICBU
aGUgc29sdXRpb24gZGVzaWduZXJzIFNIT1VMRCBzZWVrIHRvIG1pbmltaXplIHRoZSBhbW91bnQg
b2YNCj4gICAgICAgICAgICBuZXcgY29uZmlndXJhdGlvbiByZXF1aXJlZCBpbiBvcmRlciB0byB3
b3JrLiAgRm9yIGV4YW1wbGUsIGl0DQo+ICAgICAgICAgICAgaXMgYmV0dGVyIHRvIGFsbG93IHBl
ZXJzIHRvIGFkdmVydGlzZSBvciBuZWdvdGlhdGUgc3VwcG9ydA0KPiAgICAgICAgICAgIGZvciB0
aGUgc29sdXRpb24sIHJhdGhlciB0aGFuIHRvIHJlcXVpcmUgdGhhdCB0aGlzIGtub3dsZWRnZQ0K
PiAgICAgICAgICAgIHRvIGJlIGNvbmZpZ3VyZWQgYXQgZWFjaCBub2RlLg0KPiAgDQo+ICAgICAg
ICAgICAgKlBhcnRpYWxseSBDb21wbGlhbnQqLiBNb3N0IERPSUMgcGFyYW1ldGVycyBhcmUgYWR2
ZXJ0aXNlZA0KPiAgICAgICAgICAgIHVzaW5nIHRoZSBET0lDIGNhcGFiaWxpdHkgYW5ub3VuY2Vt
ZW50IG1lY2hhbmlzbS4gIEhvd2V2ZXIsDQo+ICAgICAgICAgICAgdGhlcmUgYXJlIHNvbWUgc2l0
dWF0aW9ucyB3aGVyZSBjb25maWd1cmF0aW9uIGlzIHJlcXVpcmVkLg0KPiAgICAgICAgICAgIEZv
ciBleGFtcGxlLCBhIERPSUMgbm9kZSBkZXRlY3QgdGhlIGZhY3QgdGhhdCBhIHBlZXIgbWF5IG5v
dA0KPiAgICAgICAgICAgIHN1cHBvcnQgRE9JQyB3aGVuIG5vZGVzIG9uIHRoZSBvdGhlciBzaWRl
IG9mIHRoZSBub24tDQo+ICAgICAgICAgICAgc3VwcG9ydGluZyBub2RlIGRvIHN1cHBvcnQgRE9J
QyB3aXRob3V0IGNvbmZpZ3VyYXRpb24uDQo+ICANCj4gW01DcnV6XSBDb3VsZCB5b3UgY2xhcmlm
eSBsYXN0IGV4YW1wbGU/IOKAnHdpdGhvdWcgY29uZmlndXJhdGlvbuKAnT8gSSBkbyBub3QgdW5k
ZXJzdGFuZCB3aGF0IHlvdSBtZWFudC4NCg0KSGVyZSdzIGFuIGV4YW1wbGU6DQoNCkMgLS0tLS0t
IEEgLS0tLS0tIFMNCg0KSWYgYm90aCBDIGFuZCBTIHN1cHBvcnQgRE9JQywgdGhlcmUgaXMgbm8g
d2F5IGZvciB0aGVtIHRvIHRlbGwgd2hldGhlciBBIHN1cHBvcnRzIERPSUMuIENvbnNpZGVyIHR3
byBjYXNlczoNCg0KMSkgQSBzdXBwb3J0cyBET0lDLiBCdXQgc2luY2UgQyBhbHJlYWR5IGluc2Vy
dHMgT0MtUy1GIGluIGFsbCByZXF1ZXN0cywgYW5kIFMgaW5zZXJ0cyBpdCBpbiBhbGwgYW5zd2Vy
cywgQSBwYXNzZXMgdGhlbSB0aHJvdWdoIHVuY2hhbmdlZC4NCjIpIEEgZG9lcyBub3Qgc3VwcG9y
dCBET0lDLCBidXQgcGFzc2VzIHRocm91Z2ggdW5rbm93biBBVlBzLiBTaW5jZSBPQy1TLUYgd2ls
bCBiZSB1bmtub3duIHRvIGl0LCBpdCBwYXNzZXMgaXQgdGhyb3VnaCB1bmNoYW5nZWQuDQoNCkZy
b20gdGhlIHBlcnNwZWN0aXZlIG9mIEMgYW5kIFMsIHRoZSByZXF1ZXN0cyBhbmQgYW5zd2VycyBs
b29rIGlkZW50aWNhbCBmb3IgYm90aCBjYXNlcy4gRXZlbiBpZiBBIGFjdHVhbGx5IGNoYW5nZXMg
dGhlIGNvbnRlbnQgb2YgYW4gT0MtUy1GIGF2cCwgbmVpdGhlciBlbmRwb2ludCBjYW4gdGVsbCBp
ZiB0aGUgcmVzdWx0aW5nIEFWUCBjYW1lIGZyb20gQSBvciB0aGUgb3Bwb3NpdGUgZW5kcG9pbnQu
DQoNClBlcnNvbmFsbHksIEkgdGhpbmsgdGhpcyBpcyBhIHNob3dzdG9wcGVyLiBCdXQgdGhlIHdv
cmtpbmcgZ3JvdXAgY29uc2Vuc3VzIGRpZCBub3QgYWdyZWUuDQoNCltNQ3J1el0gU2V2ZXJhbCBj
b21tZW50czoNCmEpIFRoZW4geW91IGNvbnNpZGVyIHRoaXMgcmVxdWlyZW1lbnQgYXMgInBhcnRs
eSBjb21wbGlhbnQiIHNpbmNlIHlvdSBjb25zaWRlciBjb25maWd1cmF0aW9uIGlzIHJlcXVpcmVk
IGluIGEgbm9kZSB0byBpZGVudGlmeSB3aGV0aGVyIG9yIG5vdCBpdHMgYWRqYWNlbnQgcGVlcnMg
c3VwcG9ydCBET0lDLCByaWdodD8gSWYgc28sIGNvdWxkIHlvdSBleHBsYWluIHdoeSBhIG5vZGUg
bmVlZHMgdG8ga25vdyB3aGV0aGVyIG9yIG5vdCB0aGUgcGVlciBzdXBwb3J0IERPSUMsIGEgcGFy
dCBmcm9tIHdoYXQgaXMgaW5jbHVkZWQgaW4gdGhlIGFkdmVydGlzZW1lbnQgbWVjaGFuaXNtIHdl
IGRlZmluZWQ/DQpiKSBXaGF0IGRvIHlvdSB0aGluayBpcyBhICJzaG93IHN0b3BwZXIiPyBUaGUg
bmVlZCBmb3IgY29uZmlndXJhdGlvbj8gDQoNCg0KDQo+ICANCj4gICAgUkVRIDIzOiBUaGUgc29s
dXRpb24gTVVTVCBwcm92aWRlIHN1ZmZpY2llbnQgaW5mb3JtYXRpb24gdG8gZW5hYmxlIGENCj4g
ICAgICAgICAgICBsb2FkLWJhbGFuY2luZyBub2RlIHRvIGRpdmVydCBtZXNzYWdlcyB0aGF0IGFy
ZSByZWplY3RlZCBvcg0KPiAgICAgICAgICAgIG90aGVyd2lzZSB0aHJvdHRsZWQgYnkgYW4gb3Zl
cmxvYWRlZCB1cHN0cmVhbSBub2RlIHRvIG90aGVyDQo+ICAgICAgICAgICAgdXBzdHJlYW0gbm9k
ZXMgdGhhdCBhcmUgdGhlIG1vc3QgbGlrZWx5IHRvIGhhdmUgc3VmZmljaWVudA0KPiAgICAgICAg
ICAgIGNhcGFjaXR5IHRvIHByb2Nlc3MgdGhlbS4NCj4gIA0KPiAgICAgICAgICAgICpOb3QgQ29t
cGxpYW50Ki4gRE9JQyBwcm92aWRlcyBubyBidWlsdCBpbiBtZWNoYW5pc20gdG8NCj4gICAgICAg
ICAgICBkZXRlcm1pbmUgdGhlIGJlc3QgcGxhY2UgdG8gZGl2ZXJ0IG1lc3NhZ2VzIHRoYXQgd291
bGQNCj4gICAgICAgICAgICBvdGhlcndpc2UgYmUgdGhyb3R0bGVkLiAgVGhpcyBjYW4gYmUgYWNj
b21wbGlzaGVkIHdpdGggYQ0KPiAgICAgICAgICAgIGZ1dHVyZSAibG9hZCIgZXh0ZW5zaW9uLCBv
ciB3aXRoIHByb3ByaWV0YXJ5IGxvYWQgYmFsYW5jaW5nDQo+ICAgICAgICAgICAgbWVjaGFuaXNt
cy4NCj4gIA0KPiBbTUNydXpdIFBhcnRseSBDb21wbGlhbnQuIERPSUMgT3ZlcmxvYWQgaW5mb3Jt
YXRpb24gY2FuIGJlIHVzZWQgYWxyZWFkeSBieSBwcm9wcmlldGFyeSBsb2FkLWJhbGFuY2luZyBp
bXBsZW1lbnRhdGlvbnMuDQo+IA0KPiBMb2FkIGluZm9ybWF0aW9uIHdpbGwgYmUgYSBwbHVzIHRv
IHRoaXMuDQo+IA0KDQpJIGRpc2FncmVlLCBvciBhdCBsZWFzdCB0aGluayB0aGF0IHdvdWxkIGJl
IF92ZXJ5XyBwYXJ0aWFsLiBZb3Ugd29uJ3QgaGF2ZSBhbnkgb3ZlcmxvYWQgaW5mb3JtYXRpb24g
dW5sZXNzIHRoZSBwb3RlbnRpYWwgZGl2ZXJzaW9uIHRhcmdldHMgYXJlIGFsc28gb3ZlcmxvYWRl
ZC4NCltNQ3J1el0gSW4gY2FzZSBzZXJ2ZXJzIGluIHRoZSBwb29scyBhcmUgRE9JQyBlbmFibGVk
IHRoZSBPdmVybG9hZCBpbmZvcm1hdGlvbiBpcyBwcm92aWRlZCBieSBhbGwgb2YgdGhlbSwgdW5k
ZXIgb3ZlcmxvYWQgb2NjdXJyZW5jZXMsIHRoZW4gdGhpcyBpbmZvcm1hdGlvbiBpcyB2YWxpZCAo
bWF5YmUgbm90IHN1ZmZpY2llbnQgaW4gYWxsIGNhc2VzLCBJIGFncmVlLCBidXQgdmFsaWQgaW4g
bW9zdCBvZiB0aGVtKSB0byBkaXZlcnQuDQpJbiBjYXNlIHdlIGhhdmUgbWl4ZWQgc2VydmVycyAo
RE9JQy1zdXBwb3J0aW5nIGFuZCBub24tRE9JQykgd2UgaGF2ZSBzb21lIGxpbWl0YXRpb25zIGFz
IHdlbGwuDQoNCg0KPiAgDQo+ICANCj4gICAgUkVRIDMwOiBUaGUgc29sdXRpb24gTVVTVCBOT1Qg
aW50ZXJmZXJlIHdpdGggYW55IERpYW1ldGVyLWNvbXBsaWFudA0KPiAgICAgICAgICAgIG1ldGhv
ZCB0aGF0IGEgbm9kZSBtYXkgdXNlIHRvIHByb3RlY3QgaXRzZWxmIGZyb20gb3ZlcmxvYWQNCj4g
ICAgICAgICAgICBmcm9tIG5vbi1zdXBwb3J0aW5nIG5vZGVzIG9yIGZyb20gZGVuaWFsLW9mLXNl
cnZpY2UgYXR0YWNrcy4NCj4gIA0KPiAgICAgICAgICAgICpDb21wbGlhbnQqLiBUaGUgc3BlY2lm
aWNhdGlvbiByZWNvbW1lbmRzIHRoYXQgYW55IHN1Y2gNCj4gICAgICAgICAgICBwcm90ZWN0aW9u
IG1lY2hhbmlzbSBuZWVkZWQgd2l0aG91dCBET0lDIHNob3VsZCBjb250aW51ZSB0bw0KPiAgICAg
ICAgICAgIGJlIGVtcGxveWVkIHdpdGggRE9JQy4NCj4gW01DcnV6XSBDb3VsZCB5b3UgcG9pbnQg
b3VyIHdoZXJlIGluIHRoZSBkcmFmdCBpdCBpcyBkZXNjcmliZWQ/DQoNCjkuMw0KW01DcnV6XSBJ
IGRvIG5vdCB0aGluayA5LjMgc2F5cyB3aGF0IHlvdSBtZW50aW9uZWQgaGVyZS4NCkl0IHNheXMg
IkluIHRoZSBhYnNlbmNlIG9mIGFuIG92ZXJsb2FkIGNvbnRyb2wgbWVjaGFuaXNtLi4uIi4gSXQg
aXMgbm90IHNhaWQgdGhlIERPSUMgc2hhbGwgbm90IGludGVyZmVyZSB3aXRoIGFueSBvdGhlciBE
aWFtZXRlciBtZXRob2QgZm9yIHByb3RlY3Rpb24sIHdlIG1heSBuZWVkIHRvIGFkZCB0aGlzIGlu
Zm9ybWF0aW9uIHRvIHRoZSBkcmFmdCBpbiBmYWN0Lg0KQSBwYXJ0IGZyb20gdGhhdCwgSSB0aGlu
ayA5LjMuIHNob3VsZCBzYXkgImZvciBub24tRE9JQyBzdXBwb3J0aW5nIG5vZGVzL25ldHdvcmtz
Li4uIiBub3QganVzdCAiaW4gdGhlIGFic2VuY2Ugb2YgX2FuXyBvdmVybG9hZCBjb250cm9sIG1l
Y2hhbmlzbSIuLi4NCg0KDQoNCg0KDQovQmVuLg0KDQo=


From nobody Fri Dec 12 02:29:16 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F971ACC88 for ; Fri, 12 Dec 2014 02:29:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jqm3xdQo2MD for ; Fri, 12 Dec 2014 02:29:07 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 165161ACC81 for ; Fri, 12 Dec 2014 02:29:07 -0800 (PST)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 2B5CC3B4677; Fri, 12 Dec 2014 11:29:05 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 0B5FB38413D; Fri, 12 Dec 2014 11:29:05 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Fri, 12 Dec 2014 11:29:04 +0100
From: 
To: "dime@ietf.org" 
Thread-Topic: WGLC for draft-ietf-dime-congestion-flow-attributes-01
Thread-Index: AdAIjxU+v6kXSNpPTf2oD++zGQ1VZwNZvC+A
Date: Fri, 12 Dec 2014 10:29:03 +0000
Message-ID: <2485_1418380145_548AC371_2485_9268_5_6B7134B31289DC4FAF731D844122B36E9F6D15@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <8730_1416906548_54744734_8730_3173_1_6B7134B31289DC4FAF731D844122B36E93E944@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <8730_1416906548_54744734_8730_3173_1_6B7134B31289DC4FAF731D844122B36E93E944@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.6]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E9F6D15PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.12.53924
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Oh9bVM11vsRVAffPRL_4azdpd7w
Cc: "dime-ads@tools.ietf.org" , "dime-chairs@tools.ietf.org" 
Subject: Re: [Dime] WGLC for draft-ietf-dime-congestion-flow-attributes-01
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Dec 2014 10:29:13 -0000

--_000_6B7134B31289DC4FAF731D844122B36E9F6D15PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Folks,

The WGLC for draft-ietf-dime-congestion-flow-attributes ended last Tuesday =
and no concern was expressed about the proposal to move forward this draft.
This document will be then submitted to IESG for publication.

Regards,

Lionel


De : lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Envoy=E9 : mardi 25 novembre 2014 10:09
=C0 : dime@ietf.org
Cc : dime-chairs@tools.ietf.org; dime-ads@tools.ietf.org
Objet : WGLC for draft-ietf-dime-congestion-flow-attributes-01


Folks,



As discussed at the last IETF meeting, the authors of draft-ietf-dime-conge=
stion-flow-attributes have requested for a WGLC and I think the document is=
 stable enough for it.



This email starts a two weeks WGLC for draft-ietf-dime-congestion-flow-attr=
ibutes-01 (http://tools.ietf.org/html/draft-ietf-dime-congestion-flow-attri=
butes-01)

The WGLC will end Tuesday, December 9, 2014.



Post your comments to the mailing list and if you think something needs to =
be changed, put that also into the Issue Tracker.



- Lionel & Jouni


___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.


--_000_6B7134B31289DC4FAF731D844122B36E9F6D15PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Folks,


 


The WGL=
C for draft-ietf-dime-congestion-flow-attributes ended last Tuesday and no =
concern was expressed about the proposal to move forward this draft.


This do=
cument will be then submitted to IESG for publication.


&n=
bsp;


Regards=
,


&n=
bsp;


Lionel<=
o:p>


&n=
bsp;


&n=
bsp;






De : lionel.morand@orange.com [mailt=
o:lionel.morand@orange.com]


Envoy=E9 : mardi 25 novembre 2014 10:09

=C0 : dime@ietf.org

Cc : dime-chairs@tools.ietf.org; dime-ads@tools.ietf.org

Objet : WGLC for draft-ietf-dime-congestion-flow-attributes-01<=
o:p>






 


Folks,


 


As discussed at the last IET=
F meeting, the authors of draft-ietf-dime-congestion-flow-attributes have r=
equested for a WGLC and I think the document is stable enough for it.<=
/o:p>


 


This email starts a two week=
s WGLC for draft-ietf-dime-congestion-flow-attributes-01 (http://=
tools.ietf.org/html/draft-ietf-dime-congestion-flow-attributes-01)



The WGLC will end Tuesday, D=
ecember 9, 2014.


 


Post your comments to the ma=
iling list and if you think something needs to be changed, put that also in=
to the Issue Tracker.



 


- Lionel & Jouni


 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.




______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.




--_000_6B7134B31289DC4FAF731D844122B36E9F6D15PEXCVZYM13corpora_--


From nobody Fri Dec 12 02:34:51 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0B81ACCE1 for ; Fri, 12 Dec 2014 02:34:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fshQCk9L-WXu for ; Fri, 12 Dec 2014 02:34:47 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 003741ACCE2 for ; Fri, 12 Dec 2014 02:34:46 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id A0A4ADFCDBBAF; Fri, 12 Dec 2014 10:34:43 +0000 (GMT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sBCAYiPH014508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Dec 2014 11:34:45 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.50]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 11:34:45 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: Jouni , "dime@ietf.org list" 
Thread-Topic: [Dime] early IANA assignments for DOIC
Thread-Index: AQHQFZrjiR8LPE0FZUmDu8vFd7hRhJyLwujw
Date: Fri, 12 Dec 2014 10:34:44 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/cwryKFJHNBH1j6oGFOZlL_qi7n4
Subject: Re: [Dime] early IANA assignments for DOIC
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Dec 2014 10:34:49 -0000

Hi Jouni

I am  also in favor to have an early IANA assignment of AVP codes for the D=
OIC.

Best regards

JJacques=20

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni
Envoy=E9=A0: vendredi 12 d=E9cembre 2014 00:33
=C0=A0: dime@ietf.org list
Objet=A0: [Dime] early IANA assignments for DOIC

Folks,

During the last meeting we had discussion on early IANA assignment of AVP c=
odes for the DOIC. The actual process for that is now BCPed in RFC7120. So =
far we have one request, which hardly meets the criteria of the "sufficient=
 interest in the community". Are there others (Steve is noted in the Honolu=
lu meeting minutes) who would like to see the IANA process started already =
ahead of time before the I-D leaves the WG or around that time?.

- Jouni & Lionel
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Dec 12 13:03:33 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C211A0397 for ; Fri, 12 Dec 2014 13:03:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpfvPUz4njxO for ; Fri, 12 Dec 2014 13:03:27 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34B041A8979 for ; Fri, 12 Dec 2014 13:03:23 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBCL3IOD073091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2014 15:03:20 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: 
Date: Fri, 12 Dec 2014 15:03:15 -0600
X-Mao-Original-Outgoing-Id: 440110994.94493-63f85dfde022e51eeed13782c74ca66f
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D2F1C75-95C3-4CF8-B9E6-A3E2A4ADA188@nostrum.com>
References: 
To: Jouni 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-FXErHmtifltwJJxnEvKFQHFKxg
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] early IANA assignments for DOIC
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Dec 2014 21:03:29 -0000

I would like to see this done as soon as possible. I am aware of some =
teams that plan to do early DOIC implementation and testing, and would =
like to do so with real AVP codes. Early allocation would facilitate the =
"running code" part of the IETF process.

Thanks!

Ben.

> On Dec 11, 2014, at 5:33 PM, Jouni  wrote:
>=20
> Folks,
>=20
> During the last meeting we had discussion on early IANA assignment of =
AVP codes for the DOIC. The actual process for that is now BCPed in =
RFC7120. So far we have one request, which hardly meets the criteria of =
the "sufficient interest in the community". Are there others (Steve is =
noted in the Honolulu meeting minutes) who would like to see the IANA =
process started already ahead of time before the I-D leaves the WG or =
around that time?.
>=20
> - Jouni & Lionel
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Mon Dec 15 08:43:26 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C391A802F for ; Mon, 15 Dec 2014 08:43:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.579
X-Spam-Level: *
X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0YezNe3S1vb for ; Mon, 15 Dec 2014 08:43:24 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.244.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4C41A7D85 for ; Mon, 15 Dec 2014 08:43:24 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:59722 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y0Yjv-0005Mq-ID; Mon, 15 Dec 2014 08:43:21 -0800
Message-ID: <548F0FA7.70403@usdonovans.com>
Date: Mon, 15 Dec 2014 10:43:19 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Campbell ,  "Wiehe, Ulrich (NSN - DE/Munich)" 
References: <5486F59E.4000908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235197@DEMUMBX014.nsn-intra.net> <57CA5812-ABE6-4974-8632-1BC40FA84082@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D900066815235657@DEMUMBX014.nsn-intra.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/mAj5lMhxsJzjyf3i-9a-o0xdNsE
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #8
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Dec 2014 16:43:25 -0000

I agree with Ben's wording and , given that there has been no objections 
raised, will update the document with that wording.  If there are 
objections I can make a followup change based on those objections.

Steve

On 12/11/14, 12:29 PM, Ben Campbell wrote:
>> On Dec 11, 2014, at 7:16 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:
>>
>> Ben,
>> would the following proposed text address your concern:
>>
>>    A reporting node MUST NOT change the selected algorithm during the period
>>    of time that starts when entering an overload condition and ends when it
>>    is ensured that any non-expired reacting node's OCS entry created as a
>>    result of the overload condition in the reporting node is deleted.
>>
> Yes, although I might suggest:
>
>    "A reporting node MUST NOT change the selected algorithm during the period
>    of time that starts when entering an overload condition and ends when the associated
>    OCS becomes invalid in all reacting nodes."
>   
>> In addition, is it so that outside that period the algorithm change can occur arbitrarily?
>> e.g. is it ok to change the algorithm in every second answer message while outside the period?
>> Or, is it ok to send rate while outside the period and send loss once the overload condition is entered?
>> Note that section 3.2. says:
>>
>>    Reacting nodes can use the indicated overload abatement algorithm to
>>    prepare for possible overload reports
>>
>> Should we recommend not to change the algorithm too often while outside the periode where change is prohibited?
> For "loss", it does not matter. But for algorithms that require reacting nodes to keep state, it might matter. In my opinion, reporting nodes
> should not change the algorithm very often, and not without good reason. But I don't think that needs to be a normative requirement.
>
>> Regards
>> Ulrich
>>
>> -----Original Message-----
>> From: ext Ben Campbell [mailto:ben@nostrum.com]
>> Sent: Wednesday, December 10, 2014 11:58 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich)
>> Cc: ext Steve Donovan; dime@ietf.org
>> Subject: Re: [Dime] Ulrich's suggested change #8
>>
>>
>>> On Dec 9, 2014, at 9:30 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:
>>>
>>> Steve,
>>>
>>> please see inline.
>>>
>>> Ulrich
>>>
>>>
>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>>> Sent: Tuesday, December 09, 2014 2:14 PM
>>> To: dime@ietf.org
>>> Subject: [Dime] Ulrich's suggested change #8
>>>
>>> Ulrich,
>>>
>>> For your suggested change number 8:
>>> Section 4.1.2, 8th paragraph:
>>> Existing text:
>>>   For an ongoing overload condition, a reporting node MUST NOT change
>>>   the selected algorithm during the period of time that it is in an
>>>   overload condition and, as a result, is sending OC-OLR AVPs in answer
>>>   messages.
>>>
>>> Comment: As a result of an ongoing overload condition the reporting node is
>>> sending OC-OLR AVPs containing no validity duration or a validity duration
>>> different from zero in answer messages.
>>>
>>> Proposal: Replace the paragraph with:
>>>   For an ongoing overload condition, a reporting node MUST NOT change
>>>   the selected algorithm during the period of time that it is in an
>>>   overload condition and, as a result, is sending OC-OLR AVPs
>>>   containing no validity duration or a validity duration different
>>>   from zero in answer messages.
>>> I don't see the need for the change.  The selected algorithm should not change for all overload reports relating to an overload condition, including overload reports with a validity duration of zero.
>>>  Isn't it so that when the overload condition ends (i.e. is no longer ongoing), the reporting node starts sending OLRs with validity duration of zero (for a long enough period of time)? (see end of section 4.2.1.4)
>>> The question now is whether the change of algorithm is allowed during this (long enough) period, or only after that period. I don't have a strong view. But this was not my point.
>>> My point is that the current text seems to suggest that an overload condition is ongoing as long as OC-OLR AVPs are sent in answer messages, and I think that is not true. 
>>>
>> I think the proscription should last until the reporting node is (at least reasonably) sure that all reacting nodes have removed the OCS. The original text comes closer to that than Ulrich's proposal, but I wonder if we shouldn't cast this in similar terms as we do for the part about resending zero duration OLRs.
>>
>


From nobody Mon Dec 15 09:36:19 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E912B1A86EB for ; Mon, 15 Dec 2014 09:36:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.002
X-Spam-Level: 
X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaE5s00WAU0y for ; Mon, 15 Dec 2014 09:36:15 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79EC01A86EA for ; Mon, 15 Dec 2014 09:36:15 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBFHaC6e024633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Dec 2014 17:36:12 GMT
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBFHaCPO023287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Dec 2014 18:36:12 +0100
Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 15 Dec 2014 18:36:11 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 18:36:11 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , ext Ben Campbell 
Thread-Topic: [Dime] Ulrich suggested change number 1
Thread-Index: AQHQEzn9APTOpOEpnEOsWl042ZAFN5yHKxAQgAGHrwCAAL4tAIAApwBQgABDpQCABpYMUA==
Date: Mon, 15 Dec 2014 17:36:11 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668152358BD@DEMUMBX014.nsn-intra.net>
References: <54862C38.1000403@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152350CF@DEMUMBX014.nsn-intra.net> <54883CBA.7060503@usdonovans.com>  <5BCBA1FC2B7F0B4C9D935572D900066815235563@DEMUMBX014.nsn-intra.net> <5489A118.10506@usdonovans.com>
In-Reply-To: <5489A118.10506@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.110]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 8155
X-purgate-ID: 151667::1418664973-0000658F-5B0DBDF4/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9SktSyFac8Amdyqv6gUkjTTNY0s
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich suggested change number 1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Dec 2014 17:36:19 -0000

Steve,

I'm fine with the intention and with the proposed simplification, avoiding =
misinterpretations like
"DOIC nodes sent OLRs only to DOIC nodes that are next to it" and allowing =
DOIC nodes to send OLRs to DOIC nodes that are not next to it.

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
Sent: Thursday, December 11, 2014 2:50 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: dime@ietf.org
Subject: Re: [Dime] Ulrich suggested change number 1

Ulrich,

The paragraph is only trying to state that DOIC works through non=20
supporting Diameter Agents, which is one of the requirements.

Furthermore, adjacent means "next to".  In your example, C and A1 are=20
adjacent DOIC nodes and A1 and S are adjacent DOIC nodes.  C and S are=20
never adjacent DOIC nodes because there is a DOIC node between them.

We could simplify the paragraph by saying "DOIC works through non=20
supporting Diameter Agents that properly pass unknown AVPs unchanges." =20
Maybe that would do away with the confusion about what adjacent means.

Steve


On 12/11/14, 3:55 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Ben, Steve,
>
> the confusion I think comes from the following:
> 1. the paragraph seems to try to define what "adjacent for DOIC purposes"=
 means, but gives only one example and leaves it open whether other example=
s exist.
> e.g.: Are two DOIC nodes adjacent for DOIC purposes when there is a DOIC =
supporting agent (that passes OC-specific AVPs through unchanged) on the pa=
th between them?
> 2. The paragraph says that OLRs are sent to nodes that are "adjacent for =
DOIC purpose". It's not clear whether the intention is to say
> a) OLRs are sent to adjacent DOIC nodes rather than to adjacent Diameter =
nodes, or
> b) OLRs are sent to adjacent DOIC nodes rather than to non-adjacent DOIC =
nodes.
> And it's not clear whether OLRs are also sent to DOIC nodes that are not =
adjacent for DOIC purposes.
>
> In a configuration like this:
>
> C-----A1------A2------S
>
> where C, A1 and S support DOIC and A2 does not support DOIC but passes un=
known AVPs through unchanged we need to distinguish two cases:
> 1)  A1 passes OC-specific AVPs through unchanged
> In this case C and S are adjacent for DOIC purposes, hence S sends OLRs t=
o C.
> 2)  A1 modifies/replaces OC-specific AVPs
> In this case C and A1 are adjacent for DOIC purpose and A1 and S are adja=
cent for DOIC purpose, hence S ends OLRs to A1 and A1 sends OLRs to C.
>
> Regards
> Ulrich
>
>  =20
>
> -----Original Message-----
> From: ext Ben Campbell [mailto:ben@nostrum.com]
> Sent: Thursday, December 11, 2014 12:50 AM
> To: Steve Donovan
> Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] Ulrich suggested change number 1
>
>
>> On Dec 10, 2014, at 6:29 AM, Steve Donovan  wr=
ote:
>>
>> Ulrich,
>>
>> I think I see the source of confusion.  It is meant to talk about sendin=
g to adjacent DOIC nodes but it uses the words reacting and reporting nodes=
.  I suggest changing the paragraph to the following, removing the concept =
of reporting and reacting nodes from the description.
>>
>>    While a DOIC node sends OLRs to "adjacent" DOIC nodes, nodes
>>    that are "adjacent" for DOIC purposes may not be adjacent from a
>>    Diameter, or transport, perspective.  For example, one or more
>>    Diameter agents that do not support DOIC may exist between a given
>>    pair of DOIC nodes, as long as those agents pass
>>    unknown AVPs through unchanged.  The report types described in this
>>    document can safely pass through non-supporting agents.  This may not
>>    be true for report types defined in future specifications.
>>
> I like this approach.
>
> I also note that, for a given transaction, the black-box behavior of a su=
pporting-agent that passes OC AVPs unchanged id identical to that of an a n=
on-supporting agent.
>
>
>> Regards,
>>
>
>
>> Steve
>>
>> On 12/9/14, 7:16 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>> Steve,
>>>
>>> please see inline.
>>>
>>> Ulrich
>>>
>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donova=
n
>>> Sent: Monday, December 08, 2014 11:55 PM
>>> To: dime@ietf.org
>>> Subject: [Dime] Ulrich suggested change number 1
>>>
>>> Ulrich,
>>>
>>> I'll deal with each of your suggestion in a separate email to help ensu=
re that nothing is missed.
>>>
>>> For your first suggestion:
>>> Section 3, last paragraph:
>>> Existing text:
>>>     While a reporting node sends OLRs to "adjacent" reacting nodes, nod=
es
>>>     that are "adjacent" for DOIC purposes may not be adjacent from a
>>>     Diameter, or transport, perspective.  For example, one or more
>>>     Diameter agents that do not support DOIC may exist between a given
>>>     pair of reporting and reacting nodes, as long as those agents pass
>>>     unknown AVPs through unchanged.  The report types described in this
>>>     document can safely pass through non-supporting agents.  This may n=
ot
>>>     be true for report types defined in future specifications.
>>>
>>> Comment: while this is all not wrong, the existing text may convey the =
erring
>>> impression that there cannot be a DOIC supporting agent on the path bet=
ween a
>>> reporting node and an adjacent reacting node.
>>>
>>> Proposal: It is proposed to add the following sentence at the end of th=
e paragraph:
>>>     Another example is where one or more Diameter agents that do suppor=
t
>>>     DOIC may exist between a given pair of reporting and reacting nodes=
,
>>>     as long as those agents pass OC-specific AVPs through unchanged.
>>> I don't agree with the suggested change, as the DOIC supporting agents =
might need to change the OC-specific AVPs.
>>>  I agree that in some cases DOIC supporting agents need to chan=
ge the OC-specific AVPs. However, there are also cases where DOIC supportin=
g agents do not need to change OC-specific AVPs.
>>>    I also don't understand how the paragraph implies that there cannot =
be DOIC supporting agents in the path of the request.
>>>  It does not imply that. Rather it may convey the erring impres=
sion that there cannot be a DOIC supporting agent on the path between a
>>> reporting node and an adjacent reacting node.
>>>     It is talking specifically about the case where there agents do not=
 support DOIC are in the path.
>>>  No, my understanding is that the paragraph is talking specific=
ally about what "adjacent for DOIC purposes" means. One valid example is gi=
ven (reporting node and reacting node are "adjacent for DOIC purposes" if o=
ne or more agents that do not support DOIC but pass unsupported AVPs throug=
h unchanged exist between reporting node and reacting node) and I do not pr=
opose to remove that. However, there is another important valid example (re=
porting node and reacting node are "adjacent for DOIC purposes" if one or m=
ore DOIC supporting agents that pass OC-specific AVPs through unchanged exi=
st between reporting node and reacting node), and the proposal is to add te=
xt to cover this example. 
>>> The remainder of the document makes it clear that there can be agents t=
hat do support DOIC in the path of a transaction.
>>>  that is not my point. The point is to clearly state that there=
 can be DOIC supporting agents that pass through OC-specific AVPs unchanged=
 on the path between reporting node and reacting node, and in this case the=
 reporting and reacting nodes are still regarded "adjacent for DOIC purpose=
s".
>>>
>>> I don't see the need for a change here.
>>>  I'm not proposing a modification but an addition. This additio=
n provides useful clarification and in no way is harmful
>>>
>>> Regards,
>>>
>>> Steve
>>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Mon Dec 15 09:56:18 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7201A710D for ; Mon, 15 Dec 2014 09:56:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Z15BbUgmqB7 for ; Mon, 15 Dec 2014 09:56:15 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65A61A86FC for ; Mon, 15 Dec 2014 09:56:14 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBFHuCad025423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Dec 2014 17:56:12 GMT
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBFHuB6T002645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Dec 2014 18:56:11 +0100
Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 15 Dec 2014 18:56:11 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 18:56:11 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , Ben Campbell 
Thread-Topic: [Dime] Ulrich's suggested change #15
Thread-Index: AQHQE7dJhQB5e1nbwEev114RSsJu35yHeSWggAL2Z7uAAD8mAIAACZWAgAY/jwA=
Date: Mon, 15 Dec 2014 17:56:10 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668152358E0@DEMUMBX014.nsn-intra.net>
References: <5486FE71.70205@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235215@DEMUMBX014.nsn-intra.net> <54884137.4050209@usdonovans.com> <5AB8BAC5-3CBD-432E-9631-74DF40795844@nostrum.com> <5489A498.5070203@usdonovans.com>  <5489EFAF.8010702@usdonovans.com>
In-Reply-To: <5489EFAF.8010702@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.110]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 4660
X-purgate-ID: 151667::1418666172-0000677A-4FC411C8/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ojTKhsBYKrLygILeE78DBfg81ww
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #15
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Dec 2014 17:56:17 -0000

Steve, Ben,

I'm fine with deleting the paragraph.
But for my clarification please confirm that ignoring the complete set of O=
LRs is allowed when one of these OLRs contains a report type that was not a=
dvertized, or two of the OLRs contain the same report type.

Regards
Ulrich



-----Original Message-----
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
Sent: Thursday, December 11, 2014 8:26 PM
To: Ben Campbell
Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Ulrich's suggested change #15


On 12/11/14, 12:51 PM, Ben Campbell wrote:
>> On Dec 11, 2014, at 8:05 AM, Steve Donovan  wr=
ote:
>>
>> I thought this paragraph was covering unrecognized values for all AVPs.
> I agree that's what it covered. But I think we failed to cover the unreco=
gnized AVP case. If we don't have anything to say beyond what 6733 says, th=
en it might not be strictly necessary, but it might still be worth saying t=
hat "unrecognized sub-AVPs are treated as per RFC6733".
That is probably worth saying.
>
>>   Maybe it is better to remove the paragraph entirely and make sure that=
 the definition of each AVP addresses what is done with unrecognized values=
.
> Possibly. There are AVPs where there's no such thing as an unrecognized v=
alue. There may be AVPs where the allowed values vary by algorithm. If we d=
o take that route, we probably need language here that says unrecognized va=
lues are handled as described by the AVP definition or the algorithm.
Agreed.
>
>> Steve
>>
>> On 12/10/14, 5:26 PM, Ben Campbell wrote:
>>>> On Dec 10, 2014, at 6:48 AM, Steve Donovan  =
wrote:
>>>>
>>>> Ulrich,
>>>>
>>>> Actually, the wording you suggested wasn't quite right.  It should be:
>>>>
>>>>    When receiving an OC-OLR AVP with unknown values, the overload repo=
rt
>>>>    SHOULD be silently discarded by reacting nodes and the event SHOULD
>>>>    be logged.
>>>>
>>>> It's not just about report type values but unknown values for any of t=
he AVPs in the OLR.
>>>>
>>>> This seems like a good requirement to include in the specification to =
ensure common behavior in reacting nodes.  I don't feel strongly about this=
 but I would like to hear other opinions.
>>> I think this is still not quite complete.
>>>
>>> If you receive a sub-AVP that you don't understand, then you should ign=
ore that sub-avp, not the whole OC-OLR AVP.  (Unless of course the unknown =
AVP has the m-bit set.) If you receive a known sub-AVP, with a value you do=
n't understand, the behavior should be AVP specific. For Report-Type, that =
means ignore the whole OLR.
>>>
>>> It's not clear to me whether the original text was about arbitrary avps=
, or Report-Type.
>>>
>>>> Steve
>>>>
>>>> On 12/9/14, 11:04 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>>> Hi Steve,
>>>>>
>>>>> I think it was pointed out by Ben that we do not specify behaviour of=
 a node for cases where it detects that another node is breaking the rule.
>>>>> The rule is:
>>>>>     A reporting node MUST NOT send overload reports of a type that ha=
s
>>>>>     not been advertised as supported by the reacting node.
>>>>> See section 4.2.3.
>>>>>
>>>>> Regards
>>>>> Ulrich
>>>>>
>>>>>    From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve D=
onovan
>>>>> Sent: Tuesday, December 09, 2014 2:52 PM
>>>>> To: dime@ietf.org
>>>>> Subject: [Dime] Ulrich's suggested change #15
>>>>>
>>>>> Ulrich,
>>>>>
>>>>> For your suggested change #15:
>>>>> Section 4.2.1.3, 4th paragraph:
>>>>> Existing text:
>>>>>     When receiving an OC-OLR AVPs with unknown values, a reacting nod=
e
>>>>>     SHOULD be silently discarded by reacting nodes and the event SHOU=
LD
>>>>>     be logged.
>>>>> Comment: text is confusing. Maybe the intention was to say:
>>>>>     When receiving an OC-OLR AVPs with an unsupported report type val=
ue, a reacting node
>>>>>     SHOULD silently discarded the OC-OLR AVP and the event SHOULD
>>>>>     be logged.
>>>>> But even that is not correct.
>>>>> Proposal: Remove the paragraph.
>>>>> The intent was that an OC-OLR that contains unknown values should be =
discarded.  I agree that the wording needs to be changes as you suggested. =
 I don't agree with removing the paragraph.  Can you elaborate on why you t=
hink it is not correct when changed as you suggested?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Steve
>>>>>
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Mon Dec 15 12:35:26 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2DB1A86EF for ; Mon, 15 Dec 2014 08:59:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.59
X-Spam-Level: *
X-Spam-Status: No, score=1.59 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCyVq9LdTGFR for ; Mon, 15 Dec 2014 08:59:44 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.244.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8681A86E5 for ; Mon, 15 Dec 2014 08:59:41 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:59799 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y0Yzj-0001Az-5i for dime@ietf.org; Mon, 15 Dec 2014 08:59:40 -0800
Message-ID: <548F137A.4070903@usdonovans.com>
Date: Mon, 15 Dec 2014 10:59:38 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime >> \"dime@ietf.org\"" 
Content-Type: multipart/mixed; boundary="------------050403030105000509030106"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/jM3ZH_uqYMZDd3FRJ-p3kEp9vFU
X-Mailman-Approved-At: Mon, 15 Dec 2014 12:35:23 -0800
Subject: [Dime] Updates made in initial DOIC -06
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Dec 2014 16:59:52 -0000

This is a multi-part message in MIME format.
--------------050403030105000509030106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

All,

I've made the following changes to the DOIC draft.  They are in the new 
-06 draft in github.

Ulrich's suggestions by number:

2, 3, 4, 5, 6, 7, 8, 11, 13, 14, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26

Issue 88.

The following of Ulrich's suggested changes are still open:

1, 9, 10, 12, 15, 16

I've attached a diff of the changes made so far.

Regards,

Steve



--------------050403030105000509030106
Content-Type: text/html; charset=ISO-8859-1;
 name="Diff_ draft-ietf-dime-ovli-05.txt - draft-ietf-dime-ovli-06.txt.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="Diff_ draft-ietf-dime-ovli-05.txt - draft-ietf-dime-ovli-06.";
 filename*1="txt.html"


 
 
 
 
 
 
 
 
   
   
  Diff: draft-ietf-dime-ovli-05.txt - draft-ietf-dime-ovli-06.txt 
   
 
 
  
 
  
< draft-ietf-dime-ovli-05.txt   draft-ietf-dime-ovli-06.txt >
 
      
 

      
Diameter Maintenance and Extensions (DIME)              J. Korhonen, Ed. Diameter Maintenance and Extensions (DIME)              J. Korhonen, Ed.

      
Internet-Draft                                                  Broadcom Internet-Draft                                                  Broadcom

      
Intended status: Standards Track                         S. Donovan, Ed. Intended status: Standards Track                         S. Donovan, Ed.

      

      
Expires: June 6, 2015                                        B. Campbell Expires: June 18, 2015                                       B. Campbell

      
                                                                  Oracle                                                                   Oracle

      
                                                               L. Morand                                                                L. Morand

      
                                                             Orange Labs                                                              Orange Labs

      

      
                                                        December 3, 2014                                                        December 15, 2014

      
 

      
                Diameter Overload Indication Conveyance                 Diameter Overload Indication Conveyance

      

      
                      draft-ietf-dime-ovli-05.txt                       draft-ietf-dime-ovli-06.txt

      
 

      
Abstract Abstract

      
 

      
   This specification defines a base solution for Diameter overload    This specification defines a base solution for Diameter overload

      
   control, referred to as Diameter Overload Indication Conveyance    control, referred to as Diameter Overload Indication Conveyance

      
   (DOIC).    (DOIC).

      
 

      
Requirements Requirements

      
 

      
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

      
 

      
skipping to change at page 1, line 42 skipping to change at page 1, line 42

      
   Internet-Drafts are working documents of the Internet Engineering    Internet-Drafts are working documents of the Internet Engineering

      
   Task Force (IETF).  Note that other groups may also distribute    Task Force (IETF).  Note that other groups may also distribute

      
   working documents as Internet-Drafts.  The list of current Internet-    working documents as Internet-Drafts.  The list of current Internet-

      
   Drafts is at http://datatracker.ietf.org/drafts/current/.    Drafts is at http://datatracker.ietf.org/drafts/current/.

      
 

      
   Internet-Drafts are draft documents valid for a maximum of six months    Internet-Drafts are draft documents valid for a maximum of six months

      
   and may be updated, replaced, or obsoleted by other documents at any    and may be updated, replaced, or obsoleted by other documents at any

      
   time.  It is inappropriate to use Internet-Drafts as reference    time.  It is inappropriate to use Internet-Drafts as reference

      
   material or to cite them other than as "work in progress."    material or to cite them other than as "work in progress."

      
 

      

      
   This Internet-Draft will expire on June 6, 2015.    This Internet-Draft will expire on June 18, 2015.

      
 

      
Copyright Notice Copyright Notice

      
 

      
   Copyright (c) 2014 IETF Trust and the persons identified as the    Copyright (c) 2014 IETF Trust and the persons identified as the

      
   document authors.  All rights reserved.    document authors.  All rights reserved.

      
 

      
   This document is subject to BCP 78 and the IETF Trust's Legal    This document is subject to BCP 78 and the IETF Trust's Legal

      
   Provisions Relating to IETF Documents    Provisions Relating to IETF Documents

      
   (http://trustee.ietf.org/license-info) in effect on the date of    (http://trustee.ietf.org/license-info) in effect on the date of

      
   publication of this document.  Please review these documents    publication of this document.  Please review these documents

      
 

      
skipping to change at page 2, line 25 skipping to change at page 2, line 25

      
Table of Contents Table of Contents

      
 

      
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3

      
   2.  Terminology and Abbreviations . . . . . . . . . . . . . . . .   4    2.  Terminology and Abbreviations . . . . . . . . . . . . . . . .   4

      
   3.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   5    3.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   5

      
     3.1.  Piggybacking  . . . . . . . . . . . . . . . . . . . . . .   7      3.1.  Piggybacking  . . . . . . . . . . . . . . . . . . . . . .   7

      
     3.2.  DOIC Capability Announcement  . . . . . . . . . . . . . .   8      3.2.  DOIC Capability Announcement  . . . . . . . . . . . . . .   8

      
     3.3.  DOIC Overload Condition Reporting . . . . . . . . . . . .   9      3.3.  DOIC Overload Condition Reporting . . . . . . . . . . . .   9

      
     3.4.  DOIC Extensibility  . . . . . . . . . . . . . . . . . . .  11      3.4.  DOIC Extensibility  . . . . . . . . . . . . . . . . . . .  11

      
     3.5.  Simplified Example Architecture . . . . . . . . . . . . .  12      3.5.  Simplified Example Architecture . . . . . . . . . . . . .  12

      

      
   4.  Solution Procedures . . . . . . . . . . . . . . . . . . . . .  12    4.  Solution Procedures . . . . . . . . . . . . . . . . . . . . .  13

      
     4.1.  Capability Announcement . . . . . . . . . . . . . . . . .  12      4.1.  Capability Announcement . . . . . . . . . . . . . . . . .  13

      
       4.1.1.  Reacting Node Behavior  . . . . . . . . . . . . . . .  13        4.1.1.  Reacting Node Behavior  . . . . . . . . . . . . . . .  13

      
       4.1.2.  Reporting Node Behavior . . . . . . . . . . . . . . .  13        4.1.2.  Reporting Node Behavior . . . . . . . . . . . . . . .  13

      
       4.1.3.  Agent Behavior  . . . . . . . . . . . . . . . . . . .  14        4.1.3.  Agent Behavior  . . . . . . . . . . . . . . . . . . .  14

      
     4.2.  Overload Report Processing  . . . . . . . . . . . . . . .  15      4.2.  Overload Report Processing  . . . . . . . . . . . . . . .  15

      
       4.2.1.  Overload Control State  . . . . . . . . . . . . . . .  15        4.2.1.  Overload Control State  . . . . . . . . . . . . . . .  15

      
       4.2.2.  Reacting Node Behavior  . . . . . . . . . . . . . . .  19        4.2.2.  Reacting Node Behavior  . . . . . . . . . . . . . . .  19

      
       4.2.3.  Reporting Node Behavior . . . . . . . . . . . . . . .  20        4.2.3.  Reporting Node Behavior . . . . . . . . . . . . . . .  20

      

      
     4.3.  Protocol Extensibility  . . . . . . . . . . . . . . . . .  21      4.3.  Protocol Extensibility  . . . . . . . . . . . . . . . . .  22

      
   5.  Loss Algorithm  . . . . . . . . . . . . . . . . . . . . . . .  22    5.  Loss Algorithm  . . . . . . . . . . . . . . . . . . . . . . .  22

      

      
     5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  22      5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  23

      
     5.2.  Reporting Node Behavior . . . . . . . . . . . . . . . . .  23      5.2.  Reporting Node Behavior . . . . . . . . . . . . . . . . .  23

      
     5.3.  Reacting Node Behavior  . . . . . . . . . . . . . . . . .  24      5.3.  Reacting Node Behavior  . . . . . . . . . . . . . . . . .  24

      
   6.  Attribute Value Pairs . . . . . . . . . . . . . . . . . . . .  25    6.  Attribute Value Pairs . . . . . . . . . . . . . . . . . . . .  25

      
     6.1.  OC-Supported-Features AVP . . . . . . . . . . . . . . . .  25      6.1.  OC-Supported-Features AVP . . . . . . . . . . . . . . . .  25

      
     6.2.  OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . .  25      6.2.  OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . .  25

      
     6.3.  OC-OLR AVP  . . . . . . . . . . . . . . . . . . . . . . .  26      6.3.  OC-OLR AVP  . . . . . . . . . . . . . . . . . . . . . . .  26

      
     6.4.  OC-Sequence-Number AVP  . . . . . . . . . . . . . . . . .  26      6.4.  OC-Sequence-Number AVP  . . . . . . . . . . . . . . . . .  26

      
     6.5.  OC-Validity-Duration AVP  . . . . . . . . . . . . . . . .  27      6.5.  OC-Validity-Duration AVP  . . . . . . . . . . . . . . . .  27

      
     6.6.  OC-Report-Type AVP  . . . . . . . . . . . . . . . . . . .  27      6.6.  OC-Report-Type AVP  . . . . . . . . . . . . . . . . . . .  27

      
     6.7.  OC-Reduction-Percentage AVP . . . . . . . . . . . . . . .  27      6.7.  OC-Reduction-Percentage AVP . . . . . . . . . . . . . . .  27

      

      
     6.8.  Attribute Value Pair flag rules . . . . . . . . . . . . .  27      6.8.  Attribute Value Pair flag rules . . . . . . . . . . . . .  28

      
   7.  Error Response Codes  . . . . . . . . . . . . . . . . . . . .  28    7.  Error Response Codes  . . . . . . . . . . . . . . . . . . . .  28

      
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  29    8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  29

      
     8.1.  AVP codes . . . . . . . . . . . . . . . . . . . . . . . .  29      8.1.  AVP codes . . . . . . . . . . . . . . . . . . . . . . . .  29

      
     8.2.  New registries  . . . . . . . . . . . . . . . . . . . . .  29      8.2.  New registries  . . . . . . . . . . . . . . . . . . . . .  29

      
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  30    9.  Security Considerations . . . . . . . . . . . . . . . . . . .  30

      
     9.1.  Potential Threat Modes  . . . . . . . . . . . . . . . . .  30      9.1.  Potential Threat Modes  . . . . . . . . . . . . . . . . .  30

      
     9.2.  Denial of Service Attacks . . . . . . . . . . . . . . . .  31      9.2.  Denial of Service Attacks . . . . . . . . . . . . . . . .  31

      
     9.3.  Non-Compliant Nodes . . . . . . . . . . . . . . . . . . .  32      9.3.  Non-Compliant Nodes . . . . . . . . . . . . . . . . . . .  32

      
     9.4.  End-to End-Security Issues  . . . . . . . . . . . . . . .  32      9.4.  End-to End-Security Issues  . . . . . . . . . . . . . . .  32

      
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  33    10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  33

      
 

      
skipping to change at page 8, line 36 skipping to change at page 8, line 36

      
      nodes.  In this case the DOIC agent will insert the OC-Supported-       nodes.  In this case the DOIC agent will insert the OC-Supported-

      
      Features AVP in requests that do not already contain one, telling       Features AVP in requests that do not already contain one, telling

      
      the reporting node that there is a DOIC node that will handle       the reporting node that there is a DOIC node that will handle

      
      overload abatement.  For transactions where there was an OC-       overload abatement.  For transactions where there was an OC-

      
      Supporting-Features AVP in the request, the agent will insert the       Supporting-Features AVP in the request, the agent will insert the

      
      OC-Supported-Features AVP in answers, telling the reacting node       OC-Supported-Features AVP in answers, telling the reacting node

      
      that there is a reporting node.       that there is a reporting node.

      
 

      
   The OC-Feature-Vector AVP will contain an indication of support for    The OC-Feature-Vector AVP will contain an indication of support for

      
   the loss overload abatement algorithm defined in this specification    the loss overload abatement algorithm defined in this specification

      

      
   (see Section 5).  This ensures that there is at least one commonly    (see Section 5).  This ensures that a reporting node always supports

      
   supported overload abatement algorithm between the reporting node and    at least one of the advertized abatement algorithms received in a

      
   the reacting node(s) in the path of the request.    request messages.

      
 

      
   The reporting node inserts the OC-Supported-Features AVP in all    The reporting node inserts the OC-Supported-Features AVP in all

      
   answer messages to requests that contained the OC-Supported-Features    answer messages to requests that contained the OC-Supported-Features

      
   AVP.  The contents of the reporting node's OC-Supported-Features AVP    AVP.  The contents of the reporting node's OC-Supported-Features AVP

      
   indicate the set of Diameter overload features supported by the    indicate the set of Diameter overload features supported by the

      
   reporting node.  This specification defines one exception - the    reporting node.  This specification defines one exception - the

      
   reporting node only includes an indication of support for one    reporting node only includes an indication of support for one

      
   overload abatement algorithm, independent of the number of overload    overload abatement algorithm, independent of the number of overload

      
   abatement algorithms actually supported by the reacting node.  The    abatement algorithms actually supported by the reacting node.  The

      
   overload abatement algorithm indicated is the algorithm that the    overload abatement algorithm indicated is the algorithm that the

      
 

      
skipping to change at page 9, line 29 skipping to change at page 9, line 29

      
   abatement algorithm while the reporting node is in an overload    abatement algorithm while the reporting node is in an overload

      
   condition.    condition.

      
 

      
   The individual features supported by the DOIC nodes are indicated in    The individual features supported by the DOIC nodes are indicated in

      
   the OC-Feature-Vector AVP.  Any semantics associated with the    the OC-Feature-Vector AVP.  Any semantics associated with the

      
   features will be defined in extension specifications that introduce    features will be defined in extension specifications that introduce

      
   the features.    the features.

      
 

      
   The DCA mechanism must also allow the scenario where the set of    The DCA mechanism must also allow the scenario where the set of

      
   features supported by the sender of a request and by agents in the    features supported by the sender of a request and by agents in the

      

      
   path of a request differ.  In this case, the agent updates the OC-    path of a request differ.  In this case, the agent can update the OC-

      
   Supported-Features AVP to reflect the mixture of the two sets of    Supported-Features AVP to reflect the mixture of the two sets of

      
   supported features.    supported features.

      
 

      

      
      Note: The logic to determine the content of the modified OC-       Note: The logic to determine if the content of the OC-Supported-

      
      Supported-Features AVP is out-of-scope for this specification and       Features AVP should be changed is out-of-scope for this document,

      
      is left to implementation decisions.  Care must be taken not to       as is the logic to determine the content of a modified OC-

      
      introduce interoperability issues for downstream or upstream DOIC       Supported-Features AVP.  These are left to implementation

      
      nodes.       decisions.  Care must be taken not to introduce interoperability

      
       issues for downstream or upstream DOIC nodes.

      
 

      
3.3.  DOIC Overload Condition Reporting 3.3.  DOIC Overload Condition Reporting

      
 

      
   As with DOIC capability announcement, overload condition reporting    As with DOIC capability announcement, overload condition reporting

      
   uses new AVPs (Section 6.3) to indicate an overload condition.    uses new AVPs (Section 6.3) to indicate an overload condition.

      
 

      
   The OC-OLR AVP is referred to as an overload report.  The OC-OLR AVP    The OC-OLR AVP is referred to as an overload report.  The OC-OLR AVP

      
   includes the type of report, a sequence number, the length of time    includes the type of report, a sequence number, the length of time

      
   that the report is valid and abatement algorithm specific AVPs.    that the report is valid and abatement algorithm specific AVPs.

      
 

      
 

      
skipping to change at page 10, line 14 skipping to change at page 10, line 14

      
 

      
   A report of type "HOST_REPORT" is sent to indicate the overload of a    A report of type "HOST_REPORT" is sent to indicate the overload of a

      
   specific Diameter node for the application-id indicated in the    specific Diameter node for the application-id indicated in the

      
   transaction.  When receiving an OLR of type host, a reacting node    transaction.  When receiving an OLR of type host, a reacting node

      
   applies overload abatement to what is referred to in this document as    applies overload abatement to what is referred to in this document as

      
   host-routed requests.  The reacting node applies overload abatement    host-routed requests.  The reacting node applies overload abatement

      
   on those host-routed requests which the reacting node knows will be    on those host-routed requests which the reacting node knows will be

      
   served by the server that matches the Origin-Host AVP of the received    served by the server that matches the Origin-Host AVP of the received

      
   message that contained the received OLR of type host.    message that contained the received OLR of type host.

      
 

      

      
   A report of type "REALM_REPORT" applies to realm-routed requests for    A report of type "REALM_REPORT" is sent to indicate the overload of

      
   a specific realm as indicated in the Destination-Realm AVP.    all Diameter nodes within a realm for the application-id indicated in

      
    the transaction.  When receiving an OLR of type realm, a reacting

      
    node applies overload abatement to what is referred to in this

      
    document as realm-routed requests.  The reacting node applies

      
    overload abatement on those realm-routed requests which contain a

      
    Destination-Realm AVP that matches the Origin-Realm AVP of the

      
    received message that contained the received OLR of type realm.

      
 

      
   This document assumes that there is a single source for realm-reports    This document assumes that there is a single source for realm-reports

      
   for a given realm, or that if multiple nodes can send realm reports,    for a given realm, or that if multiple nodes can send realm reports,

      
   that each such node has full knowledge of the overload state of the    that each such node has full knowledge of the overload state of the

      
   entire realm.  A reacting node cannot distinguish between receiving    entire realm.  A reacting node cannot distinguish between receiving

      
   realm-reports from a single node, or from multiple nodes.    realm-reports from a single node, or from multiple nodes.

      
 

      
      Note: Known issues exist if multiple sources for overload reports       Note: Known issues exist if multiple sources for overload reports

      
      which apply to the same Diameter entity exist.  Reacting nodes       which apply to the same Diameter entity exist.  Reacting nodes

      
      have no way of determining the source and, as such, will treat       have no way of determining the source and, as such, will treat

      
 

      
skipping to change at page 10, line 38 skipping to change at page 10, line 44

      
      abatement treatment to be applied for indeterminate periods of       abatement treatment to be applied for indeterminate periods of

      
      time.       time.

      
 

      
   Reporting nodes are responsible for determining the need for a    Reporting nodes are responsible for determining the need for a

      
   reduction of traffic.  The method for making this determination is    reduction of traffic.  The method for making this determination is

      
   implementation specific and depend on the type of overload report    implementation specific and depend on the type of overload report

      
   being generated.  A host-report, for instance, will generally be    being generated.  A host-report, for instance, will generally be

      
   generated by tracking utilization of resources required by the host    generated by tracking utilization of resources required by the host

      
   to handle transactions for the Diameter application.  A realm-report    to handle transactions for the Diameter application.  A realm-report

      
   generally impacts the traffic sent to multiple hosts and, as such,    generally impacts the traffic sent to multiple hosts and, as such,

      

      
   requires tracking the capacity all servers for realm-routed requests    requires tracking the capacity of all servers able to handle realm-

      
   for the application and realm.    routed requests for the application and realm.

      
 

      
   Once a reporting node determines the need for a reduction in traffic,    Once a reporting node determines the need for a reduction in traffic,

      
   it uses the DOIC defined AVPs to report on the condition.  These AVPs    it uses the DOIC defined AVPs to report on the condition.  These AVPs

      
   are included in answer messages sent or relayed by the reporting    are included in answer messages sent or relayed by the reporting

      
   node.  The reporting node indicates the overload abatement algorithm    node.  The reporting node indicates the overload abatement algorithm

      
   that is to be used to handle the traffic reduction in the OC-    that is to be used to handle the traffic reduction in the OC-

      
   Supported-Features AVP.  The OC-OLR AVP is used to communicate    Supported-Features AVP.  The OC-OLR AVP is used to communicate

      
   information about the requested reduction.    information about the requested reduction.

      
 

      
   Reacting nodes, upon receipt of an overload report, are responsible    Reacting nodes, upon receipt of an overload report, are responsible

      
 

      
skipping to change at page 11, line 17 skipping to change at page 11, line 24

      
 

      
   Two types of overload abatement treatment are defined, diversion and    Two types of overload abatement treatment are defined, diversion and

      
   throttling.  Reacting nodes are responsible for determining which    throttling.  Reacting nodes are responsible for determining which

      
   treatment is appropriate for individual requests.    treatment is appropriate for individual requests.

      
 

      
   As the conditions that lead to the generation of the overload report    As the conditions that lead to the generation of the overload report

      
   change the reporting node can send new overload reports requesting    change the reporting node can send new overload reports requesting

      
   greater reduction if the condition gets worse or less reduction if    greater reduction if the condition gets worse or less reduction if

      
   the condition improves.  The reporting node sends an overload report    the condition improves.  The reporting node sends an overload report

      
   with a duration of zero to indicate that the overload condition has    with a duration of zero to indicate that the overload condition has

      

      
   ended and need for use of the abatement algorithm to reduce traffic    ended and abatement is no longer needed.

      
   sent is no longer needed. 

      
 

      
   The reacting node also determines when the overload report expires    The reacting node also determines when the overload report expires

      
   based on the OC-Validity-Duration AVP in the overload report and    based on the OC-Validity-Duration AVP in the overload report and

      
   stops applying the abatement algorithm when the report expires.    stops applying the abatement algorithm when the report expires.

      
 

      
3.4.  DOIC Extensibility 3.4.  DOIC Extensibility

      
 

      
   The DOIC solution is designed to be extensible.  This extensibility    The DOIC solution is designed to be extensible.  This extensibility

      
   is based on existing Diameter based extensibility mechanisms, along    is based on existing Diameter based extensibility mechanisms, along

      
   with the DOIC capability announcement mechanism.    with the DOIC capability announcement mechanism.

      
 

      
skipping to change at page 13, line 42 skipping to change at page 13, line 50

      
   answer message for that transaction.    answer message for that transaction.

      
 

      
   A reporting node MUST NOT include the OC-Supported-Features AVP, OC-    A reporting node MUST NOT include the OC-Supported-Features AVP, OC-

      
   OLR AVP or any other overload control AVPs defined in extension    OLR AVP or any other overload control AVPs defined in extension

      
   drafts in response messages for transactions where the request    drafts in response messages for transactions where the request

      
   message does not include the OC-Supported-Features AVP.  Lack of the    message does not include the OC-Supported-Features AVP.  Lack of the

      
   OC-Supported-Features AVP in the request message indicates that there    OC-Supported-Features AVP in the request message indicates that there

      
   is no reacting node for the transaction.    is no reacting node for the transaction.

      
 

      
   A reporting node knows what overload control functionality is    A reporting node knows what overload control functionality is

      

      
   supported by the reacting node based on the content of the OC-    supported by the reacting node based on the content or absence of the

      
   Feature-Vector AVP in the request message.    OC-Feature-Vector AVP within the OC-Supported-Features AVP in the

      
    request message.

      
 

      
   A reporting node MUST indicate support for one and only one abatement    A reporting node MUST indicate support for one and only one abatement

      
   algorithm in the OC-Feature-Vector AVP.  The abatement algorithm    algorithm in the OC-Feature-Vector AVP.  The abatement algorithm

      
   selected MUST indicate the abatement algorithm the reporting node    selected MUST indicate the abatement algorithm the reporting node

      
   wants the reacting node to use when the reporting node enters an    wants the reacting node to use when the reporting node enters an

      
   overload condition.    overload condition.

      
 

      
   The abatement algorithm selected MUST be from the set of abatement    The abatement algorithm selected MUST be from the set of abatement

      
   algorithms contained in the request message's OC-Feature-Vector AVP.    algorithms contained in the request message's OC-Feature-Vector AVP.

      
 

      
   A reporting node that selects the loss algorithm may do so by    A reporting node that selects the loss algorithm may do so by

      
   including the OC-Feature-Vector AVP with an explicit indication of    including the OC-Feature-Vector AVP with an explicit indication of

      
   the loss algorithm, or it MAY omit OC-Feature-Vector.  If it selects    the loss algorithm, or it MAY omit OC-Feature-Vector.  If it selects

      
   a different algorithm, it MUST include the OC-Feature-Vector AVP with    a different algorithm, it MUST include the OC-Feature-Vector AVP with

      
   an explicit indication of the selected algorithm.    an explicit indication of the selected algorithm.

      
 

      

      
   For an ongoing overload condition, a reporting node MUST NOT change    A reporting node MUST NOT change the selected algorithm during the

      
   the selected algorithm during the period of time that it is in an    period of time that starts when entering an overload condition and

      
   overload condition and, as a result, is sending OC-OLR AVPs in answer    ends when the associated OCS becomes invalid in all reacting nodes.

      
   messages. 

      
 

      
   The reporting node MAY change the overload abatement algorithm    The reporting node MAY change the overload abatement algorithm

      
   indicated in the OC-Supported-Features AVP at any time as long as no    indicated in the OC-Supported-Features AVP at any time as long as no

      
   previously sent OLRs may be active.    previously sent OLRs may be active.

      
 

      
   The reporting node SHOULD indicate support for other DOIC features    The reporting node SHOULD indicate support for other DOIC features

      
   defined in extension drafts that it supports and that apply to the    defined in extension drafts that it supports and that apply to the

      
   transaction.    transaction.

      
 

      
      Note: Not all DOIC features will apply to all Diameter       Note: Not all DOIC features will apply to all Diameter

      
 

      
skipping to change at page 15, line 11 skipping to change at page 15, line 18

      
   behavior when there is no OC-Supported-Features AVP in an answer    behavior when there is no OC-Supported-Features AVP in an answer

      
   message for a transaction that contained the OC-Supported-Features    message for a transaction that contained the OC-Supported-Features

      
   AVP in the request message.    AVP in the request message.

      
 

      
   For a Diameter Agent to take on reporting node behavior for a non    For a Diameter Agent to take on reporting node behavior for a non

      
   supporting Diameter endpoint the Diameter Agent MUST include the OC-    supporting Diameter endpoint the Diameter Agent MUST include the OC-

      
   Supported-Features AVP in answer messages it receives that do not    Supported-Features AVP in answer messages it receives that do not

      
   contain the OC-Supported-Features AVP.    contain the OC-Supported-Features AVP.

      
 

      
   As with a Diameter endpoint taking on reporting node behavior, a    As with a Diameter endpoint taking on reporting node behavior, a

      

      
   Diameter Agent MUST only include the OC-Supported-Features AVP in    Diameter Agent MUST NOT include the OC-Supported-Features AVP in

      
   answer messages for transactions where the request message received    answer messages for transactions where the request message received

      

      
   by the Diameter Agent had an OC-Supported-Features AVP.    by the Diameter Agent had no OC-Supported-Features AVP.

      
 

      
   If a request message already has the OC-Supported-Features AVP then a    If a request message already has the OC-Supported-Features AVP then a

      
   Diameter Agent MAY leave it unchanged in the relayed message or MAY    Diameter Agent MAY leave it unchanged in the relayed message or MAY

      
   modify it to reflect the features appropriate for the transaction.    modify it to reflect the features appropriate for the transaction.

      
 

      
      For instance, if the agent supports a superset of the features       For instance, if the agent supports a superset of the features

      
      reported by the reacting node then the agent might choose, based       reported by the reacting node then the agent might choose, based

      
      on local policy, to advertise that superset of features to the       on local policy, to advertise that superset of features to the

      
      reporting node.       reporting node.

      
 

      
 

      
skipping to change at page 16, line 8 skipping to change at page 16, line 19

      
 

      
   o  A host-type OCS entry for each Destination-Host to which it sends    o  A host-type OCS entry for each Destination-Host to which it sends

      
      host-type requests and       host-type requests and

      
 

      
   o  A realm-type OCS entry for each Destination-Realm to which it    o  A realm-type OCS entry for each Destination-Realm to which it

      
      sends realm-type requests.       sends realm-type requests.

      
 

      
   A host-type OCS entry is identified by the pair of application-id and    A host-type OCS entry is identified by the pair of application-id and

      
   the node's DiameterIdentity.    the node's DiameterIdentity.

      
 

      

      
   A realm-type OCS entry is identified by the pair of application-d and    A realm-type OCS entry is identified by the pair of application-id

      
   realm.    and realm.

      
 

      
   The host-type and realm-type OCS entries MAY include the following    The host-type and realm-type OCS entries MAY include the following

      
   information (the actual information stored is an implementation    information (the actual information stored is an implementation

      
   decision):    decision):

      
 

      
   o  Sequence number (as received in OC-OLR)    o  Sequence number (as received in OC-OLR)

      
 

      
   o  Time of expiry (derived from OC-Validity-Duration AVP received in    o  Time of expiry (derived from OC-Validity-Duration AVP received in

      
      the OC-OLR AVP and time of reception of the message carrying OC-       the OC-OLR AVP and time of reception of the message carrying OC-

      
      OLR AVP)       OLR AVP)

      
 

      
skipping to change at page 17, line 10 skipping to change at page 17, line 19

      
4.2.1.3.  Reacting Node Maintenance of Overload Control State 4.2.1.3.  Reacting Node Maintenance of Overload Control State

      
 

      
   When a reacting node receives an OC-OLR AVP, it MUST determine if it    When a reacting node receives an OC-OLR AVP, it MUST determine if it

      
   is for an existing or new overload condition.    is for an existing or new overload condition.

      
 

      
      Note: For the remainder of this section the term OLR refers to the       Note: For the remainder of this section the term OLR refers to the

      
      combination of the contents of the received OC-OLR AVP and the       combination of the contents of the received OC-OLR AVP and the

      
      abatement algorithm indicated in the received OC-Supported-       abatement algorithm indicated in the received OC-Supported-

      
      Features AVP.       Features AVP.

      
 

      

      
   When receiving an answer message with multiple OLRs or different    When receiving an answer message with multiple OLRs of different

      
   types, a reporting node MUST process each received OLR.    supported report types, a reporting node MUST process each received

      
    OLR.

      
 

      
   When receiving an OC-OLR AVPs with unknown values, a reacting node    When receiving an OC-OLR AVPs with unknown values, a reacting node

      
   SHOULD be silently discarded by reacting nodes and the event SHOULD    SHOULD be silently discarded by reacting nodes and the event SHOULD

      
   be logged.    be logged.

      
 

      
   The OLR is for an existing overload condition if a reacting node has    The OLR is for an existing overload condition if a reacting node has

      
   an OCS that matches the received OLR.    an OCS that matches the received OLR.

      
 

      
   For a host-report this means it matches the application-id and the    For a host-report this means it matches the application-id and the

      
   host's DiameterIdentity in an existing host OCS entry.    host's DiameterIdentity in an existing host OCS entry.

      
 

      
skipping to change at page 20, line 14 skipping to change at page 20, line 28

      
 

      
   If the overload abatement treatment results in throttling of the    If the overload abatement treatment results in throttling of the

      
   request and if the reacting node is an agent then the agent MUST send    request and if the reacting node is an agent then the agent MUST send

      
   an appropriate error as defined in Section 7.    an appropriate error as defined in Section 7.

      
 

      
   The behavior of reacting nodes that are Diameter endpoints when    The behavior of reacting nodes that are Diameter endpoints when

      
   throttling requests depends on the application and is outside the    throttling requests depends on the application and is outside the

      
   scope of this specification.    scope of this specification.

      
 

      
   In the case that the OCS entry indicated no traffic was to be sent to    In the case that the OCS entry indicated no traffic was to be sent to

      

      
   the overloaded entity and the validity duration expires or has a    the overloaded entity and the validity duration expires then overload

      
   validity duration of zero ("0"), meaning that the reporting node has    abatement associated with the overload report MUST be ended in a

      
   explicitly signaled the end of the overload condition then overload 

      
   abatement associated with the overload abatement MUST be ended in a 

      
   controlled fashion.    controlled fashion.

      
 

      
4.2.3.  Reporting Node Behavior 4.2.3.  Reporting Node Behavior

      
 

      
   If there is an active OCS entry then a reporting node SHOULD include    If there is an active OCS entry then a reporting node SHOULD include

      
   the OC-OLR AVP in all answer messages to requests that contain the    the OC-OLR AVP in all answer messages to requests that contain the

      
   OC-Supported-Features AVP and that match the active OCS entry.    OC-Supported-Features AVP and that match the active OCS entry.

      
 

      
      Note: A request matches if the application-id in the request       Note: A request matches if the application-id in the request

      
      matches the application-id in any active OCS entry and if the       matches the application-id in any active OCS entry and if the

      
 

      
skipping to change at page 22, line 4 skipping to change at page 22, line 18

      
   include new traffic abatement algorithms, new report types or other    include new traffic abatement algorithms, new report types or other

      
   new functionality.    new functionality.

      
 

      
   When defining a new extension that requires new normative behavior,    When defining a new extension that requires new normative behavior,

      
   the specification MUST define a new feature for the OC-Feature-    the specification MUST define a new feature for the OC-Feature-

      
   Vector.  This feature bit is used to communicate support for the new    Vector.  This feature bit is used to communicate support for the new

      
   feature.    feature.

      
 

      
   The extension MAY define new AVPs for use in DOIC Capability    The extension MAY define new AVPs for use in DOIC Capability

      
   Announcement and for use in DOIC Overload reporting.  These new AVPs    Announcement and for use in DOIC Overload reporting.  These new AVPs

      

      
   SHOULD be defined to be extensions to the OC-Supported-Features and    SHOULD be defined to be extensions to the OC-Supported-Features or

      
   OC-OLR AVPs defined in this document.    OC-OLR AVPs defined in this document.

      
 

      
   [RFC6733] defined Grouped AVP extension mechanisms apply.  This    [RFC6733] defined Grouped AVP extension mechanisms apply.  This

      
   allows, for example, defining a new feature that is mandatory to be    allows, for example, defining a new feature that is mandatory to be

      
   understood even when piggybacked on an existing application.    understood even when piggybacked on an existing application.

      
 

      
   The handling of feature bits in the OC-Feature-Vector AVP that are    The handling of feature bits in the OC-Feature-Vector AVP that are

      
   not associated with overload abatement algorithms MUST be specified    not associated with overload abatement algorithms MUST be specified

      
   by the extensions that define the features.    by the extensions that define the features.

      
 

      
 

      
skipping to change at page 23, line 28 skipping to change at page 23, line 42

      
   2.  A new Diameter request is generated by the application running on    2.  A new Diameter request is generated by the application running on

      
       the reacting node.        the reacting node.

      
 

      
   3.  The reacting node determines that an active overload report    3.  The reacting node determines that an active overload report

      
       applies to the request, as indicated by the corresponding OCS        applies to the request, as indicated by the corresponding OCS

      
       entry.        entry.

      
 

      
   4.  The reacting node determines if overload abatement treatment    4.  The reacting node determines if overload abatement treatment

      
       should be applied to the request.  One approach that could be        should be applied to the request.  One approach that could be

      
       taken for each request is to select a random number between 1 and        taken for each request is to select a random number between 1 and

      

      
       100.  If the random number is less than the indicated reduction        100.  If the random number is less than or equal to the indicated

      
       percentage then the request is given abatement treatment,        reduction percentage then the request is given abatement

      
       otherwise the request is given normal routing treatment.        treatment, otherwise the request is given normal routing

      
        treatment.

      
 

      
5.2.  Reporting Node Behavior 5.2.  Reporting Node Behavior

      
 

      
   The method a reporting node uses to determine the amount of traffic    The method a reporting node uses to determine the amount of traffic

      
   reduction required to address an overload condition is an    reduction required to address an overload condition is an

      
   implementation decision.    implementation decision.

      
 

      
   When a reporting node that has selected the loss abatement algorithm    When a reporting node that has selected the loss abatement algorithm

      
   determines the need to request a reduction in traffic, it includes an    determines the need to request a reduction in traffic, it includes an

      
   OC-OLR AVP in response messages as described in Section 4.2.3.    OC-OLR AVP in response messages as described in Section 4.2.3.

      
 

      
skipping to change at page 24, line 21 skipping to change at page 24, line 32

      
   indicated in the OC-Supported-Features AVP is the loss algorithm, the    indicated in the OC-Supported-Features AVP is the loss algorithm, the

      
   reacting node MUST apply abatement treatment to the requested    reacting node MUST apply abatement treatment to the requested

      
   percentage of request messages sent.    percentage of request messages sent.

      
 

      
      Note: The loss algorithm is a stateless algorithm.  As a result,       Note: The loss algorithm is a stateless algorithm.  As a result,

      
      the reacting node does not guarantee that there will be an       the reacting node does not guarantee that there will be an

      
      absolute reduction in traffic sent.  Rather, it guarantees that       absolute reduction in traffic sent.  Rather, it guarantees that

      
      the requested percentage of new requests will be given abatement       the requested percentage of new requests will be given abatement

      
      treatment.       treatment.

      
 

      

      
   When applying overload abatement treatment for the load abatement    When applying overload abatement treatment for the loss abatement

      
   algorithm, the reacting node MUST abate the requested percentage of    algorithm, the reacting node MUST abate the requested percentage of

      
   requests that would have otherwise been sent to the reporting host or    requests that would have otherwise been sent to the reporting host or

      
   realm.    realm.

      
 

      
   If reacting node comes out of the 100 percent traffic reduction as a    If reacting node comes out of the 100 percent traffic reduction as a

      
   result of the overload report timing out, the following concerns are    result of the overload report timing out, the following concerns are

      
   RECOMMENDED to be applied.  The reacting node sending the traffic    RECOMMENDED to be applied.  The reacting node sending the traffic

      
   should be conservative and, for example, first send "probe" messages    should be conservative and, for example, first send "probe" messages

      
   to learn the overload condition of the overloaded node before    to learn the overload condition of the overloaded node before

      
   converging to any traffic amount/rate decided by the sender.  Similar    converging to any traffic amount/rate decided by the sender.  Similar

      
   concerns apply in all cases when the overload report times out unless    concerns apply in all cases when the overload report times out unless

      
   the previous overload report stated 0 percent reduction.    the previous overload report stated 0 percent reduction.

      
 

      

      
   If the reacting node does not receive an OLR in messages sent to the    If the reacting node does not receive an OLR in response to messages

      
   formerly overloaded node then the reacting node SHOULD slowly    sent to the formerly overloaded node then the reacting node SHOULD

      
   increase the rate of traffic sent to the overloaded node.    slowly increase the rate of traffic sent to the overloaded node.

      
 

      
   When an active overload report expires, it is suggested that the    When an active overload report expires, it is suggested that the

      
   reacting node progressively decrease the amount of traffic given    reacting node progressively decrease the amount of traffic given

      
   abatement treatment, until the reduction is completely removed and no    abatement treatment, until the reduction is completely removed and no

      
   traffic is given abatement treatment.    traffic is given abatement treatment.

      
 

      
      The goal of this behavior is to reduce the probability of overload       The goal of this behavior is to reduce the probability of overload

      
      condition thrashing where an immediate transition from 100%       condition thrashing where an immediate transition from 100%

      
      reduction to 0% reduction results in the reporting node moving       reduction to 0% reduction results in the reporting node moving

      
      quickly back into an overload condition.       quickly back into an overload condition.

      
 

      
skipping to change at page 25, line 31 skipping to change at page 25, line 38

      
   serves two purposes.  First, it announces a node's support for the    serves two purposes.  First, it announces a node's support for the

      
   DOIC solution in general.  Second, it contains the description of the    DOIC solution in general.  Second, it contains the description of the

      
   supported DOIC features of the sending node.  The OC-Supported-    supported DOIC features of the sending node.  The OC-Supported-

      
   Features AVP MUST be included in every Diameter request message a    Features AVP MUST be included in every Diameter request message a

      
   DOIC supporting node sends.    DOIC supporting node sends.

      
 

      
      OC-Supported-Features ::= < AVP Header: TBD1 >       OC-Supported-Features ::= < AVP Header: TBD1 >

      
                                [ OC-Feature-Vector ]                                 [ OC-Feature-Vector ]

      
                              * [ AVP ]                               * [ AVP ]

      
 

      

      
   The OC-Feature-Vector sub-AVP is used to announce the DOIC features 

      
   supported by the DOIC node, in the form of a flag-bits field in which 

      
   each bit announces one feature or capability supported by the node 

      
   (see Section 6.2).  The absence of the OC-Feature-Vector AVP 

      
   indicates that only the default traffic abatement algorithm described 

      
   in this specification is supported. 

      
                                                                          

      
6.2.  OC-Feature-Vector AVP 6.2.  OC-Feature-Vector AVP

      
 

      
   The OC-Feature-Vector AVP (AVP code TBD6) is of type Unsigned64 and    The OC-Feature-Vector AVP (AVP code TBD6) is of type Unsigned64 and

      
   contains a 64 bit flags field of announced capabilities of a DOIC    contains a 64 bit flags field of announced capabilities of a DOIC

      
   node.  The value of zero (0) is reserved.    node.  The value of zero (0) is reserved.

      
 

      
   The OC-Feature-Vector sub-AVP is used to announce the DOIC features    The OC-Feature-Vector sub-AVP is used to announce the DOIC features

      
   supported by the DOIC node, in the form of a flag-bits field in which    supported by the DOIC node, in the form of a flag-bits field in which

      

      
   each bit announces one feature or capability supported by the node    each bit announces one feature or capability supported by the node.

      
   (see Section 6.2).  The absence of the OC-Feature-Vector AVP    The absence of the OC-Feature-Vector AVP in request messages

      
   indicates that only the default traffic abatement algorithm described    indicates that only the default traffic abatement algorithm described

      

      
   in this specification is supported.    in this specification is supported.  The absence of the OC- Feature-

      
    Vector AVP in answer messages indicates that the default traffic

      
    abatement algorithm described in this specification is selected

      
    (while other traffic abatement algorithms may be supported), and no

      
    features other than abatement algorithms are supported.

      
 

      
   The following capabilities are defined in this document:    The following capabilities are defined in this document:

      
 

      
   OLR_DEFAULT_ALGO (0x0000000000000001)    OLR_DEFAULT_ALGO (0x0000000000000001)

      
 

      
      When this flag is set by the a DOIC reacting node it means that       When this flag is set by the a DOIC reacting node it means that

      
      the default traffic abatement (loss) algorithm is supported.  When       the default traffic abatement (loss) algorithm is supported.  When

      
      this flag is set by a DOIC reporting node it means that the loss       this flag is set by a DOIC reporting node it means that the loss

      
      algorithm will be used for requested overload abatement.       algorithm will be used for requested overload abatement.

      
 

      
6.3.  OC-OLR AVP 6.3.  OC-OLR AVP

      
 

      
   The OC-OLR AVP (AVP code TBD2) is of type Grouped and contains the    The OC-OLR AVP (AVP code TBD2) is of type Grouped and contains the

      
   information necessary to convey an overload report on an overload    information necessary to convey an overload report on an overload

      
   condition at the reporting node.  The OC-OLR AVP does not explicitly    condition at the reporting node.  The OC-OLR AVP does not explicitly

      
   contain all information needed by the reacting node to decide whether    contain all information needed by the reacting node to decide whether

      

      
   a subsequent request must undergo abatement using the received    a subsequent request must undergo abatement using the selected

      
   reduction percentage.  The value of the OC-Report-Type AVP within the    abatement algorithm.  The value of the OC-Report-Type AVP within the

      
   OC-OLR AVP indicates which implicit information is relevant for this    OC-OLR AVP indicates which implicit information is relevant for this

      
   decision (see Section 6.6).  The application the OC-OLR AVP applies    decision (see Section 6.6).  The application the OC-OLR AVP applies

      
   to is the same as the Application-Id found in the Diameter message    to is the same as the Application-Id found in the Diameter message

      
   header.  The host or realm the OC-OLR AVP concerns is determined from    header.  The host or realm the OC-OLR AVP concerns is determined from

      
   the Origin-Host AVP and/or Origin-Realm AVP found in the    the Origin-Host AVP and/or Origin-Realm AVP found in the

      
   encapsulating Diameter command.  The OC-OLR AVP is intended to be    encapsulating Diameter command.  The OC-OLR AVP is intended to be

      
   sent only by a reporting node.    sent only by a reporting node.

      
 

      
      OC-OLR ::= < AVP Header: TBD2 >       OC-OLR ::= < AVP Header: TBD2 >

      
                 < OC-Sequence-Number >                  < OC-Sequence-Number >

      
 

      
skipping to change at page 28, line 28 skipping to change at page 28, line 31

      
      +--------------------------------------------------+----+----+       +--------------------------------------------------+----+----+

      
      |OC-Report-Type         TBD5  6.6      Enumerated  |    | V  |       |OC-Report-Type         TBD5  6.6      Enumerated  |    | V  |

      
      +--------------------------------------------------+----+----+       +--------------------------------------------------+----+----+

      
      |OC-Reduction                                      |    |    |       |OC-Reduction                                      |    |    |

      
      |  -Percentage          TBD8  6.7      Unsigned32  |    | V  |       |  -Percentage          TBD8  6.7      Unsigned32  |    | V  |

      
      +--------------------------------------------------+----+----+       +--------------------------------------------------+----+----+

      
      |OC-Feature-Vector      TBD6  6.2      Unsigned64  |    | V  |       |OC-Feature-Vector      TBD6  6.2      Unsigned64  |    | V  |

      
      +--------------------------------------------------+----+----+       +--------------------------------------------------+----+----+

      
 

      
   As described in the Diameter base protocol [RFC6733], the M-bit usage    As described in the Diameter base protocol [RFC6733], the M-bit usage

      

      
   for a given AVP in a given command may be defined by the    for a given AVP in a given command may be defined by the application.

      
   application.. 

      
 

      
7.  Error Response Codes 7.  Error Response Codes

      
 

      
   When a DOIC node rejects a Diameter request due to overload, the DOIC    When a DOIC node rejects a Diameter request due to overload, the DOIC

      
   node MUST select an appropriate error response code.  This    node MUST select an appropriate error response code.  This

      
   determination is made based on the probability of the request    determination is made based on the probability of the request

      
   succeeding if retried on a different path.    succeeding if retried on a different path.

      
 

      
   A reporting node rejecting a Diameter request due to an overload    A reporting node rejecting a Diameter request due to an overload

      

      
   condition SHOULD send a DIAMETER-TOO-BUSY error response, if it can    condition SHOULD send a DIAMETER_TOO_BUSY error response, if it can

      
   assume that the same request may succeed on a different path.    assume that the same request may succeed on a different path.

      
 

      
   If a reporting node knows or assumes that the same request will not    If a reporting node knows or assumes that the same request will not

      
   succeed on a different path, DIAMETER_UNABLE_TO_COMPLY error response    succeed on a different path, DIAMETER_UNABLE_TO_COMPLY error response

      
   SHOULD be used.  Retrying would consume valuable resources during an    SHOULD be used.  Retrying would consume valuable resources during an

      
   occurrence of overload.    occurrence of overload.

      
 

      
      For instance, if the request arrived at the reporting node without       For instance, if the request arrived at the reporting node without

      
      a Destination-Host AVP then the reporting node might determine       a Destination-Host AVP then the reporting node might determine

      
      that there is an alternative Diameter node that could successfully       that there is an alternative Diameter node that could successfully

      
 

      
skipping to change at page 30, line 5 skipping to change at page 30, line 5

      
   values can be added into the registry using the Specification    values can be added into the registry using the Specification

      
   Required policy.  [RFC5226].    Required policy.  [RFC5226].

      
 

      
   A new "Overload Report Type" registry is required.  The registry must    A new "Overload Report Type" registry is required.  The registry must

      
   contain the following:    contain the following:

      
 

      
      Report Type Value       Report Type Value

      
 

      
      Specification - the specification that defines the new value.       Specification - the specification that defines the new value.

      
 

      

      
   See Section 6.2 for the initial assignment in the registry.  New    See Section 6.6 for the initial assignment in the registry.  New

      
   types can be added using the Specification Required policy [RFC5226].    types can be added using the Specification Required policy [RFC5226].

      
 

      
9.  Security Considerations 9.  Security Considerations

      
 

      
   DOIC gives Diameter nodes the ability to request that downstream    DOIC gives Diameter nodes the ability to request that downstream

      
   nodes send fewer Diameter requests.  Nodes do this by exchanging    nodes send fewer Diameter requests.  Nodes do this by exchanging

      
   overload reports that directly effect this reduction.  This exchange    overload reports that directly effect this reduction.  This exchange

      
   is potentially subject to multiple methods of attack, and has the    is potentially subject to multiple methods of attack, and has the

      
   potential to be used as a Denial-of-Service (DoS) attack vector.    potential to be used as a Denial-of-Service (DoS) attack vector.

      
 


     
 

     
 End of changes. 32 change blocks. 

     
64 lines changed or deleted 66 lines changed or added

     

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ 

   

   
   
X-Generator: pyht 0.35


--------------050403030105000509030106--


From nobody Mon Dec 15 12:42:50 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1727F1A8985 for ; Mon, 15 Dec 2014 12:42:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZN7W65xbxQgc for ; Mon, 15 Dec 2014 12:42:42 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC3F61A88B1 for ; Mon, 15 Dec 2014 12:42:41 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBFKgcs2016272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Dec 2014 20:42:39 GMT
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBFKgYQR012348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Dec 2014 21:42:35 +0100
Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 15 Dec 2014 21:42:34 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 21:42:34 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Ben Campbell , Steve Donovan 
Thread-Topic: [Dime] Ulrich's suggested change #16
Thread-Index: AQHQE7lXyc+G3J0M1EW8kbPFxFEQNZyHfq1QgANENfD///h3AIAAAngAgAZo/cA=
Date: Mon, 15 Dec 2014 20:42:33 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668152359A7@DEMUMBX014.nsn-intra.net>
References: <548701E1.3060502@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235234@DEMUMBX014.nsn-intra.net> <54884556.90108@usdonovans.com> <9B6C0FB1-B3D5-4050-B79D-E429A440CE79@nostrum.com> <5489F246.5040801@usdonovans.com> <8D4FC2F7-30F8-41AF-9F19-209BB48FCB9D@nostrum.com>
In-Reply-To: <8D4FC2F7-30F8-41AF-9F19-209BB48FCB9D@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.110]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 7238
X-purgate-ID: 151667::1418676159-0000658F-254AF523/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/NWPFo0smoKE01S2ti6_nt0H2HXI
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #16
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Dec 2014 20:42:47 -0000

Steve,
can you please summarize the status of #16. I'm getting lost.

Regards
Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com]=20
Sent: Thursday, December 11, 2014 8:45 PM
To: Steve Donovan
Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Ulrich's suggested change #16


> On Dec 11, 2014, at 1:36 PM, Steve Donovan  wro=
te:
>=20
>=20
> On 12/11/14, 1:03 PM, Ben Campbell wrote:
>>> On Dec 10, 2014, at 7:06 AM, Steve Donovan  w=
rote:
>>>=20
>>> Ulrich,
>>>=20
>>> I agree with your assumptions below.  For the third one, the only time =
it is possible, at least from a DOIC perspective, to send to another host i=
s if it is a realm-routed request.  I might also change the "not overloaded=
" to "less overloaded".
>>>=20
>>> I do think the statements can be improved to differentiate between beha=
vior for host reports and realm reports.
>>>=20
>>> How about the following:
>>>    For OLRs of type host, if the request is a host-routed request then =
the reacting node SHOULD
>>>    apply throttling abatement treatment to the request.
>>>=20
>>>    For OLRs of type host, If the request is a realm-routed request then=
 the reacting node
>>>    SHOULD apply diversion abatement treatment to the request.
>> Personally, I think that should be non-normative. Or if normative, no st=
ronger than MAY. I agree it's a good choice, but I think we can leave it to=
 the market to enforce.
> If we make it non normative then we probably need an additional statement=
 along the lines of "the reacting node MUST attempt to reduce traffic by th=
e amount requested in the OLR" if we don't already have it somewhere else i=
n the document.

Agreed

>>=20
>> I think there when we distinguish request-type, we need to consider _whe=
n_. For example, an agent may _receive_ a realm routed request but _send_ a=
 host-routed request. And for a client, that may be even more subtle.
>>=20
>> This really does seem like a case of server selection.
> I don't think it's that subtle.  If server selection hasn't already happe=
ned for a request and that request is selected for abatement and the reques=
t would have otherwise been routed to an overloaded host then the request s=
hould/may be diverted to another server.
>=20
> Server selection could have happened as a result of a previous transactio=
n specifying the host for subsequent transactions or by the presence of the=
 Destination-Host in the message when it arrives at an agent.  It could hav=
e also already happened as a result of configuration.

In the case of a client, the decision on whether to divert vs just not send=
 a request may be heavily influenced by the client application.  (Not neces=
sarily the _Diameter_ application.)  In the case of either, a node might ha=
ve local knowledge that a 2nd server can handle everything the first server=
 can handle. Even if a downstream node performed server selection, a node w=
ith such knowledge might override it. We don't necessarily need to talk abo=
ut that sort of thing, but we should avoid language that forbids it.


>>=20
>>>    For OLRs of type realm, the reacting node SHOULD
>>>    apply throttling abatement treatment to the request, independent of =
the type (host-routed or
>>>    realm-routed) of request.
>> Again, I think this should not be normative. In this case this is pretty=
 much a statement of fact--you simply cannot reasonably divert given the wa=
y that Diameter routing works. I suppose there might be a case where a node=
 has some magical knowledge that realm2 can handle anything that realm1 can=
, and could divert to a different realm (which we probably still don't want=
 to forbid.)
>>=20
>>>=20
>>> Regards,
>>>=20
>>> Steve
>>>=20
>>> On 12/9/14, 11:29 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>> Steve,
>>>> yes, then, maybe, the definition of Diversion is not correct?
>>>> What are other people's views?
>>>>=20
>>>> My assumption was:
>>>> If a host is overloaded, it does not help to direct traffic to that ho=
st via a different path.
>>>> If a realm is overloaded, it does not help to direct traffic to that r=
ealm via a different path.
>>>> If a host is overloaded, it helps to select an alternative (not overlo=
aded) host (if possible) and direct traffic to that host.
>>>> If a realm is overloaded, there never is an alternative (not overloade=
d) realm to which traffic could be directed.
>>>>=20
>>>> With the current definition of Diversion, Diversion is no appropriate =
means to address host overload and is no appropriate means to address realm=
 overload. It may be ok for agent overload only.
>>>>=20
>>>> Regards
>>>> Ulrich
>>>>=20
>>>> From: DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] On Behalf Of ext Steve Donovan
>>>> Sent: Tuesday, December 09, 2014 3:06 PM
>>>> To:
>>>> dime@ietf.org
>>>>=20
>>>> Subject: [Dime] Ulrich's suggested change #16
>>>>=20
>>>> Ulrich,
>>>>=20
>>>> For your suggested change #16:
>>>> Section 4.2.2, 5th and 6th paragraph:
>>>> Existing text:
>>>>    If the request is a host-routed request then the reacting node SHOU=
LD
>>>>    apply throttling abatement treatment to the request.
>>>>      If the request is a realm-routed request then the reacting node
>>>>    SHOULD apply diversion abatement treatment to the request.
>>>>=20
>>>> Comment: I don't think so. If the reacting node selects the server and
>>>> then detects that the selected server is overloaded and then detects t=
hat
>>>> the request does not survive (i.e. is subject to abatement), then the =
reacting
>>>> node SHOULD apply diversion treatment (i.e. select an alternative serv=
er if possible).
>>>> If the reacting node does not select the server (either a. because the=
 server was
>>>> already selected by a downstream node, or b. because the server will b=
e selected
>>>> by an upstream node) then there is no point in applying diversion and =
the reacting
>>>> node SHOULD apply throttling of requests that do not survive.
>>>>=20
>>>> Proposal: replace the paragraphs with:
>>>>    If the reacting node does not select the server then it SHOULD appl=
y
>>>>    throttling abatement to the request.
>>>>=20
>>>>    If the reacting node selects the server then it SHOULD apply divers=
ion
>>>>    abatement treatment (i.e. select an alternative server if possible)=
 to
>>>>    the request.
>>>> Diversion is not selecting an alternative node to handle the request. =
 Diversion is selecting an alternative route to the selected node.
>>>>=20
>>>> Whether it is appropriate to select an alternative node for a request =
is an application decision that probably changes on a per command-code basi=
s within the application. Logic like this is outside the scope of the DOIC =
specification.
>>>>=20
>>>> The text is correct based on the definition of diversion.
>>>>=20
>>>> Regards,
>>>>=20
>>>> Steve
>>>>=20
>>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime


From nobody Tue Dec 16 06:12:40 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153DF1A1B5F for ; Tue, 16 Dec 2014 06:12:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeGx7m5-_nZK for ; Tue, 16 Dec 2014 06:12:35 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.244.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17A71A1B26 for ; Tue, 16 Dec 2014 06:12:35 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63202 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y0srX-0000iP-SI; Tue, 16 Dec 2014 06:12:34 -0800
Message-ID: <54903DCF.2090402@usdonovans.com>
Date: Tue, 16 Dec 2014 08:12:31 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Maria Cruz Bartolome ,  Ben Campbell 
References: <545792B6.8030502@usdonovans.com> <5464FD42.8080709@usdonovans.com> <9939_1415923523_54654743_9939_948_1_6B7134B31289DC4FAF731D844122B36E8DB63C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <, > <087A34937E64E74E848732CFF8354B9209863A54@ESESSMB101.ericsson.se> <24987_1416213505_5469B401_24987_4151_1_judb1lo2cnj5m4v6mdt5aec1.1416213483721@email.android.com>  <54748CEA.3020705@usdonovans.com> <19072_1416939968_5474C9C0_19072_1519_1_6B7134B31289DC4FAF731D844122B36E941639@PEXCVZYM13.corporate.adroot.infra.ftgroup> <547E09C0.5080305@usdonovans.com>   <547F46D5.7060800@usdonovans.! com> <087A34937E64E74E848732CFF8354B920987F790@ESESSMB101.ericsson.se>  <087A34937E64E74E848732CFF8354B9209880865@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209880865@ESESSMB101.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/orvDfLJoKrbcgfJCuLp_NrhH-_g
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Updates to DOIC -05
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Dec 2014 14:12:38 -0000

How about the following:

Therefore, before
    applying local message throttling, a reporting node needs to check if
    these messages are covered by an active overload occurrence,


Regards,

Steve

On 12/12/14, 2:04 AM, Maria Cruz Bartolome wrote:
> 2119 language is not required in my opinion, as long as the message is transmitted.
> Cheers
> /MCruz
>
> -----Original Message-----
> From: Ben Campbell [mailto:ben@nostrum.com]
> Sent: jueves, 11 de diciembre de 2014 0:46
> To: Maria Cruz Bartolome
> Cc: Steve Donovan; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); lionel.morand@orange.com; dime@ietf.org
> Subject: Re: [Dime] Updates to DOIC -05
>
>
>> On Dec 10, 2014, at 9:09 AM, Maria Cruz Bartolome  wrote:
>>
>> Dear all,
>>   
>> I have the following proposal, for first paragraph
>> Now:
>> Therefore, before
>>     applying local message throttling, a reporting node needs to check if
>>     these messages match existing OCS entries,
>>   
>> Proposal
>> Therefore, before
>>     applying local message throttling, a reporting node MAY check if
>>     these messages match existing OCS entries,
>>   
>> I think the reporting node may or not check whether the received messages match a "delegated" active OCS. This is a processing consuming task that could be avoided if the reporting node uses different criteria to choose messages to drop/reject. This is up to  implementation.
> I am okay with it being up to the implementation. I think the point of the warning is to let implementers know they need to consider this.
>
> But I wonder why you want to add 2119 language when it didn't have it before?
>
>
>>   
>> Best regards
>> /MCruz
>>   
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
>> Sent: miércoles, 03 de diciembre de 2014 18:22
>> To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); lionel.morand@orange.com;
>> Ben Campbell
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] Updates to DOIC -05
>>   
>> I have attempted to address both Lionel's and Jean-Jacques' suggestions with the following text:
>>
>>     When a reporting node sends an OLR, it effectively delegates any
>>     necessary throttling to downstream nodes.  If the reporting node also
>>     locally throttles the same set of messages, the overall number of
>>     throttled requests may be higher than intended.  Therefore, before
>>     applying local message throttling, a reporting node needs to check if
>>     these messages match existing OCS entries, indicating that these
>>     messages have survived throttling applied by downstream nodes that
>>     have received the related OLR.
>>   
>>     However, even if the set of messages match existing OCS entries, the
>>     reporting node can still apply other abatement methods such as
>>     diversion.  The reporting node might also need to throttle requests
>>     for reasons other than overload.  For example, an agent or server
>>     might have a configured rate limit for each client, and throttle
>>     requests that exceed that limit, even if such requests had already
>>     been candidates for throttling by downstream nodes.  The reporting
>>     node also has the option to send new OLRs requesting greater
>>     reductions in traffic, reducing the need for local throttling.
>>
>> Steve
>>
>> On 12/3/14, 6:19 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>> Dear all
>>   
>> To continue on my remark , I would complement the Steve's text with " can update the reduction of traffic it requires from the reacting nodes(s) by sending new overload reports" as hereafter:
>>   
>>     Therefore, if a
>>     reporting node needs to apply local throttling on a set of messages
>>     that match existing OCS entries, it needs to consider
>>     the impact of throttling by downstream nodes and can update the reduction of traffic it requires from the reacting nodes(s) by sending new overload reports.
>>   
>> Best regards
>>   
>> JJacques
>>   
>>   
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN,
>> JEAN-JACQUES (JEAN-JACQUES) Envoyé : mercredi 3 décembre 2014 11:29 À
>> : Steve Donovan; lionel.morand@orange.com; Ben Campbell Cc :
>> dime@ietf.org Objet : Re: [Dime] Updates to DOIC -05
>>   
>> Dear all
>>   
>> I am not against the new proposed texts from Steve or Ben to clarify this topic.
>>   
>> My point is that, when  the reporting node has sent an OLR requiring  a traffic reduction , there is first a reaction time before receiving reduced traffic, and second even if the traffic has been reduced, it can still exceed the capacity of the reporting node  that has no other choice than to throttle the received reduced traffic (if no diversion). This can happen when the traffic at the source (reacting node) before throttling is increasing quickly, so the traffic reduced  according to the received OLR may  remain too high .  Then, if the reporting node has nevertheless to do some throttle, it will certainly react by new OLRs requiring a higher traffic reduction from the reacting nodes. This is a dynamic process, where the reporting node adjust the  traffic  reduction it requires according to what it receives .
>>   
>> As Ben  I also think this is a guidance , and I think it is good to bring some guidance.
>>   
>> Best regards
>>   
>> JJacques
>>   
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
>> Envoyé : mardi 2 décembre 2014 19:50 À : lionel.morand@orange.com; Ben
>> Campbell Cc : dime@ietf.org Objet : Re: [Dime] Updates to DOIC -05
>>   
>> Lionel,
>>
>> The two paragraphs together now say the following:
>>
>>     When a reporting node sends an OLR, it effectively delegates any
>>     necessary throttling to downstream nodes.  If the reporting node also
>>     locally throttles the same set of messages, the overall number of
>>     throttled request may be higher than intended.  Therefore, if a
>>     reporting node needs to apply local throttling on a set of messages
>>     that match or overlap with existing OCS entries, it needs to consider
>>     the impact of throttling by downstream nodes.
>>   
>>     However, when the reporting node sends an OLR downstream, it might
>>     still need to apply other abatement methods such as diversion.  The
>>     reporting node might also need to throttle requests for reasons other
>>     than overload.  For example, an agent or server might have a
>>     configured rate limit for each client, and throttle requests that
>>     exceed that limit, even if such requests had already been candidates
>>     for throttling by downstream nodes.
>> Do you see the need for further clarification?
>>
>> Steve
>>
>> On 11/25/14, 12:26 PM, lionel.morand@orange.com wrote:
>> I'm OK with the idea of the text proposed by Ben.
>> I would just make clear that throttling is applicable to the fact of sending/forwarding requests (cf. definition). A reporting node may apply local throttling if it is an agent. But if it is a server, it can either drop the exceeded number of requests (no response sent to the downstream) or send a specific DIAMETER-TOO-BUSY response. I think that this clarification is somehow missing in the document.
>>   
>> Regards,
>>   
>> Lionel
>>   
>> -----Message d'origine-----
>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoyé : mardi 25
>> novembre 2014 15:07 À : Ben Campbell; MORAND Lionel IMT/OLN Cc :
>> Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; Maria Cruz Bartolome
>> Objet : Re: [Dime] Updates to DOIC -05
>>   
>> I'm ok with Ben's wording and will make the change unless I hear objections on the list.
>>   
>> Steve
>>   
>> On 11/21/14, 5:01 PM, Ben Campbell wrote:
>> On reflection, I think there might be a subtlety here. The resulting offered-load may still exceed the reporting node's current capacity. This can be true even if it's sent an OLR (and thus has related OCS). As mentioned in the surrounding node needs to still be able to protect itself, possibly by throttling. Therefore, I propose the sentence take the form of non-normative guidance. For example:
>>   
>> "When a reporting node sends an OLR, it effectively delegates any necessary throttling to downstream nodes.  If the reporting node also locally throttles the same set of messages, the overall number of throttled request may be higher than intended. Therefore, if a reporting node needs to apply local throttling on a set of messages that match or overlap with existing OCS entries, it needs to consider the impact of throttling by downstream nodes."
>>   
>>    
>> On Nov 17, 2014, at 2:38 AM, lionel.morand@orange.com wrote:
>>   
>> I can live with the text proposed by Ulrich. But what is wrong with:
>>   
>> " Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which an active OCS applies." ?
>>   
>> Envoyé depuis mon Sony Xperia SP d'Orange
>>   
>> ---- Maria Cruz Bartolome a écrit ----
>>   
>>   
>> Section 4.2.3, 13th paragraph, 2nd sentence:
>> Existing text: Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the OLR applies.
>> Proposed text: Therefore, the reporting node SHOULD NOT apply throttling to the set of messages to which the sent OLR applies.
>>   
>> [LM] I would say that the reporting node will not remember the previously sent OLR, but will take care that there is an active OCS.
>> SRD> I'm ok with Ulrich's change.
>>   
>> [LM] and this is incorrect but not fundamental. The reporting node does not have to "remember" a previously sent OLR. What it will do is to refer to existing OCS to know that throttling should not be applied. An OCS is a consequence of an sent OLR but it is not an OLR itself. But not fundamental here.
>>   
>> [MCruz] I am ok with Ulrich's change. It does not mean that the reporting node needs to "remember" a previously sent OLR, though. The change only proposes to "identify" which OLR we refer to.
>>   
>> Best regards
>> /MCruz
>>   
>>   
>> _____________________________________________________________________
>> ____________________________________________________
>>   
>> 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
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>   
>>   
>>   
>> ______________________________________________________________________
>> ___________________________________________________
>>   
>> 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
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Tue Dec 16 06:51:08 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2D91A1B22 for ; Tue, 16 Dec 2014 06:51:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9BnmJXKmpO2 for ; Tue, 16 Dec 2014 06:51:05 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.244.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA5B31A1B0C for ; Tue, 16 Dec 2014 06:51:04 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63247 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y0tSm-0001XP-2G; Tue, 16 Dec 2014 06:51:03 -0800
Message-ID: <549046D3.3090104@usdonovans.com>
Date: Tue, 16 Dec 2014 08:50:59 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  Ben Campbell 
References: <5486FE71.70205@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235215@DEMUMBX014.nsn-intra.net> <54884137.4050209@usdonovans.com> <5AB8BAC5-3CBD-432E-9631-74DF40795844@nostrum.com> <5489A498.5070203@usdonovans.com>  <5489EFAF.8010702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152358E0@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668152358E0@DEMUMBX014.nsn-intra.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/jJfp7QtXu8B6RnV2VdHA_EAY7bU
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #15
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Dec 2014 14:51:06 -0000

I'll delete the paragraph.

Do we need explicit statements for the two conditions below?

Steve


On 12/15/14, 11:56 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve, Ben,
>
> I'm fine with deleting the paragraph.
> But for my clarification please confirm that ignoring the complete set of OLRs is allowed when one of these OLRs contains a report type that was not advertized, or two of the OLRs contain the same report type.
>
> Regards
> Ulrich
>
>
>
> -----Original Message-----
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> Sent: Thursday, December 11, 2014 8:26 PM
> To: Ben Campbell
> Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] Ulrich's suggested change #15
>
>
> On 12/11/14, 12:51 PM, Ben Campbell wrote:
>>> On Dec 11, 2014, at 8:05 AM, Steve Donovan  wrote:
>>>
>>> I thought this paragraph was covering unrecognized values for all AVPs.
>> I agree that's what it covered. But I think we failed to cover the unrecognized AVP case. If we don't have anything to say beyond what 6733 says, then it might not be strictly necessary, but it might still be worth saying that "unrecognized sub-AVPs are treated as per RFC6733".
> That is probably worth saying.
>>>    Maybe it is better to remove the paragraph entirely and make sure that the definition of each AVP addresses what is done with unrecognized values.
>> Possibly. There are AVPs where there's no such thing as an unrecognized value. There may be AVPs where the allowed values vary by algorithm. If we do take that route, we probably need language here that says unrecognized values are handled as described by the AVP definition or the algorithm.
> Agreed.
>>> Steve
>>>
>>> On 12/10/14, 5:26 PM, Ben Campbell wrote:
>>>>> On Dec 10, 2014, at 6:48 AM, Steve Donovan  wrote:
>>>>>
>>>>> Ulrich,
>>>>>
>>>>> Actually, the wording you suggested wasn't quite right.  It should be:
>>>>>
>>>>>     When receiving an OC-OLR AVP with unknown values, the overload report
>>>>>     SHOULD be silently discarded by reacting nodes and the event SHOULD
>>>>>     be logged.
>>>>>
>>>>> It's not just about report type values but unknown values for any of the AVPs in the OLR.
>>>>>
>>>>> This seems like a good requirement to include in the specification to ensure common behavior in reacting nodes.  I don't feel strongly about this but I would like to hear other opinions.
>>>> I think this is still not quite complete.
>>>>
>>>> If you receive a sub-AVP that you don't understand, then you should ignore that sub-avp, not the whole OC-OLR AVP.  (Unless of course the unknown AVP has the m-bit set.) If you receive a known sub-AVP, with a value you don't understand, the behavior should be AVP specific. For Report-Type, that means ignore the whole OLR.
>>>>
>>>> It's not clear to me whether the original text was about arbitrary avps, or Report-Type.
>>>>
>>>>> Steve
>>>>>
>>>>> On 12/9/14, 11:04 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>>>> Hi Steve,
>>>>>>
>>>>>> I think it was pointed out by Ben that we do not specify behaviour of a node for cases where it detects that another node is breaking the rule.
>>>>>> The rule is:
>>>>>>      A reporting node MUST NOT send overload reports of a type that has
>>>>>>      not been advertised as supported by the reacting node.
>>>>>> See section 4.2.3.
>>>>>>
>>>>>> Regards
>>>>>> Ulrich
>>>>>>
>>>>>>     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>>>>>> Sent: Tuesday, December 09, 2014 2:52 PM
>>>>>> To: dime@ietf.org
>>>>>> Subject: [Dime] Ulrich's suggested change #15
>>>>>>
>>>>>> Ulrich,
>>>>>>
>>>>>> For your suggested change #15:
>>>>>> Section 4.2.1.3, 4th paragraph:
>>>>>> Existing text:
>>>>>>      When receiving an OC-OLR AVPs with unknown values, a reacting node
>>>>>>      SHOULD be silently discarded by reacting nodes and the event SHOULD
>>>>>>      be logged.
>>>>>> Comment: text is confusing. Maybe the intention was to say:
>>>>>>      When receiving an OC-OLR AVPs with an unsupported report type value, a reacting node
>>>>>>      SHOULD silently discarded the OC-OLR AVP and the event SHOULD
>>>>>>      be logged.
>>>>>> But even that is not correct.
>>>>>> Proposal: Remove the paragraph.
>>>>>> The intent was that an OC-OLR that contains unknown values should be discarded.  I agree that the wording needs to be changes as you suggested.  I don't agree with removing the paragraph.  Can you elaborate on why you think it is not correct when changed as you suggested?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Steve
>>>>>>
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Tue Dec 16 06:54:31 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566C11A1B4E for ; Tue, 16 Dec 2014 06:54:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmJnCPVtNlgv for ; Tue, 16 Dec 2014 06:54:27 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.244.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4E71A1B0C for ; Tue, 16 Dec 2014 06:54:27 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63248 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y0tW4-0005yx-CX; Tue, 16 Dec 2014 06:54:26 -0800
Message-ID: <549047A0.4060503@usdonovans.com>
Date: Tue, 16 Dec 2014 08:54:24 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  ext Ben Campbell 
References: <548701E1.3060502@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235234@DEMUMBX014.nsn-intra.net> <54884556.90108@usdonovans.com> <9B6C0FB1-B3D5-4050-B79D-E429A440CE79@nostrum.com> <5489F246.5040801@usdonovans.com> <8D4FC2F7-30F8-41AF-9F19-209BB48FCB9D@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668152359A7@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668152359A7@DEMUMBX014.nsn-intra.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ipH6FDwz_wrTzMgo4Tv2cTUnc2I
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #16
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Dec 2014 14:54:29 -0000

Ulrich,

I still think the following statements are sufficient:

    For OLRs of type host, if the request is a host-routed request then the reacting node SHOULD
    apply throttling abatement treatment to the request.

    For OLRs of type host, if the request is a realm-routed request then the reacting node
    SHOULD apply diversion abatement treatment to the request.

    For OLRs of type realm, the reacting node SHOULD
    apply throttling abatement treatment to the request, independent of the type (host-routed or
    realm-routed) of request.

Regards,

Steve

On 12/15/14, 2:42 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
> can you please summarize the status of #16. I'm getting lost.
>
> Regards
> Ulrich
>
> -----Original Message-----
> From: ext Ben Campbell [mailto:ben@nostrum.com]
> Sent: Thursday, December 11, 2014 8:45 PM
> To: Steve Donovan
> Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] Ulrich's suggested change #16
>
>
>> On Dec 11, 2014, at 1:36 PM, Steve Donovan  wrote:
>>
>>
>> On 12/11/14, 1:03 PM, Ben Campbell wrote:
>>>> On Dec 10, 2014, at 7:06 AM, Steve Donovan  wrote:
>>>>
>>>> Ulrich,
>>>>
>>>> I agree with your assumptions below.  For the third one, the only time it is possible, at least from a DOIC perspective, to send to another host is if it is a realm-routed request.  I might also change the "not overloaded" to "less overloaded".
>>>>
>>>> I do think the statements can be improved to differentiate between behavior for host reports and realm reports.
>>>>
>>>> How about the following:
>>>>     For OLRs of type host, if the request is a host-routed request then the reacting node SHOULD
>>>>     apply throttling abatement treatment to the request.
>>>>
>>>>     For OLRs of type host, If the request is a realm-routed request then the reacting node
>>>>     SHOULD apply diversion abatement treatment to the request.
>>> Personally, I think that should be non-normative. Or if normative, no stronger than MAY. I agree it's a good choice, but I think we can leave it to the market to enforce.
>> If we make it non normative then we probably need an additional statement along the lines of "the reacting node MUST attempt to reduce traffic by the amount requested in the OLR" if we don't already have it somewhere else in the document.
> Agreed
>
>>> I think there when we distinguish request-type, we need to consider _when_. For example, an agent may _receive_ a realm routed request but _send_ a host-routed request. And for a client, that may be even more subtle.
>>>
>>> This really does seem like a case of server selection.
>> I don't think it's that subtle.  If server selection hasn't already happened for a request and that request is selected for abatement and the request would have otherwise been routed to an overloaded host then the request should/may be diverted to another server.
>>
>> Server selection could have happened as a result of a previous transaction specifying the host for subsequent transactions or by the presence of the Destination-Host in the message when it arrives at an agent.  It could have also already happened as a result of configuration.
> In the case of a client, the decision on whether to divert vs just not send a request may be heavily influenced by the client application.  (Not necessarily the _Diameter_ application.)  In the case of either, a node might have local knowledge that a 2nd server can handle everything the first server can handle. Even if a downstream node performed server selection, a node with such knowledge might override it. We don't necessarily need to talk about that sort of thing, but we should avoid language that forbids it.
>
>
>>>>     For OLRs of type realm, the reacting node SHOULD
>>>>     apply throttling abatement treatment to the request, independent of the type (host-routed or
>>>>     realm-routed) of request.
>>> Again, I think this should not be normative. In this case this is pretty much a statement of fact--you simply cannot reasonably divert given the way that Diameter routing works. I suppose there might be a case where a node has some magical knowledge that realm2 can handle anything that realm1 can, and could divert to a different realm (which we probably still don't want to forbid.)
>>>
>>>> Regards,
>>>>
>>>> Steve
>>>>
>>>> On 12/9/14, 11:29 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>>> Steve,
>>>>> yes, then, maybe, the definition of Diversion is not correct?
>>>>> What are other people's views?
>>>>>
>>>>> My assumption was:
>>>>> If a host is overloaded, it does not help to direct traffic to that host via a different path.
>>>>> If a realm is overloaded, it does not help to direct traffic to that realm via a different path.
>>>>> If a host is overloaded, it helps to select an alternative (not overloaded) host (if possible) and direct traffic to that host.
>>>>> If a realm is overloaded, there never is an alternative (not overloaded) realm to which traffic could be directed.
>>>>>
>>>>> With the current definition of Diversion, Diversion is no appropriate means to address host overload and is no appropriate means to address realm overload. It may be ok for agent overload only.
>>>>>
>>>>> Regards
>>>>> Ulrich
>>>>>
>>>>> From: DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] On Behalf Of ext Steve Donovan
>>>>> Sent: Tuesday, December 09, 2014 3:06 PM
>>>>> To:
>>>>> dime@ietf.org
>>>>>
>>>>> Subject: [Dime] Ulrich's suggested change #16
>>>>>
>>>>> Ulrich,
>>>>>
>>>>> For your suggested change #16:
>>>>> Section 4.2.2, 5th and 6th paragraph:
>>>>> Existing text:
>>>>>     If the request is a host-routed request then the reacting node SHOULD
>>>>>     apply throttling abatement treatment to the request.
>>>>>       If the request is a realm-routed request then the reacting node
>>>>>     SHOULD apply diversion abatement treatment to the request.
>>>>>
>>>>> Comment: I don't think so. If the reacting node selects the server and
>>>>> then detects that the selected server is overloaded and then detects that
>>>>> the request does not survive (i.e. is subject to abatement), then the reacting
>>>>> node SHOULD apply diversion treatment (i.e. select an alternative server if possible).
>>>>> If the reacting node does not select the server (either a. because the server was
>>>>> already selected by a downstream node, or b. because the server will be selected
>>>>> by an upstream node) then there is no point in applying diversion and the reacting
>>>>> node SHOULD apply throttling of requests that do not survive.
>>>>>
>>>>> Proposal: replace the paragraphs with:
>>>>>     If the reacting node does not select the server then it SHOULD apply
>>>>>     throttling abatement to the request.
>>>>>
>>>>>     If the reacting node selects the server then it SHOULD apply diversion
>>>>>     abatement treatment (i.e. select an alternative server if possible) to
>>>>>     the request.
>>>>> Diversion is not selecting an alternative node to handle the request.  Diversion is selecting an alternative route to the selected node.
>>>>>
>>>>> Whether it is appropriate to select an alternative node for a request is an application decision that probably changes on a per command-code basis within the application. Logic like this is outside the scope of the DOIC specification.
>>>>>
>>>>> The text is correct based on the definition of diversion.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Steve
>>>>>
>>>>>
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Tue Dec 16 07:02:42 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD911A1B4E for ; Tue, 16 Dec 2014 07:02:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.778
X-Spam-Level: 
X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqjEPocezEJC for ; Tue, 16 Dec 2014 07:02:33 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.244.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 649711A1B59 for ; Tue, 16 Dec 2014 07:02:33 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63255 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y0tds-0003r9-HX; Tue, 16 Dec 2014 07:02:32 -0800
Message-ID: <54904984.9080802@usdonovans.com>
Date: Tue, 16 Dec 2014 09:02:28 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Campbell 
References: <5486FA8B.6040503@usdonovans.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/j53o-oO5mJNygKSdb2pN5XYhSRE
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested changes #9 and #10
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Dec 2014 15:02:40 -0000

Ben,

See inline.

Steve

On 12/10/14, 5:06 PM, Ben Campbell wrote:
>> On Dec 9, 2014, at 7:35 AM, Steve Donovan  wrote:
>>
>> Ulrich,
>>
>> Suggested changes 9 and 10 are linked so I'll deal with them in a single email:
>>
>> Section 4.1.3, 1st paragraph:
>> Existing text:
>>     Diameter Agents that support DOIC SHOULD ensure that all messages
>>     relayed by the agent contain the OC-Supported-Features AVP.
>> Comment: The SHOULD in the first line is not correct based on my next comment.
>> Proposal: Delete the first paragraph.
>>
>> Section 4.1.3, 4th paragraph:
>> Existing text:
>>     A Diameter Agent SHOULD take on reporting node behavior for Diameter
>>     endpoints that do not support the DOIC solution.  A Diameter Agent
>>     detects that a Diameter endpoint does not support DOIC reporting node
>>     behavior when there is no OC-Supported-Features AVP in an answer
>>     message for a transaction that contained the OC-Supported-Features
>>     AVP in the request message.
>> Comment: The first sentence can reasonably only apply to Diameter agents that are immediate peers to the non-supporting Diameter endpoint. We cannot expect a far-away-agent to take on reporting node behavior when all upstream agents and the server do not support DOIC. Furthermore: When the non-supporting server has two DOIC supporting immediate peer agents which both take on reporting node behavior we end up in problems similar to those identified in the note in section 3.3.
>> Proposal:Replace the paragaph with:
>>     A Diameter Agent that is an immediate peer to the Diameter endpoint
>>     that does not support DOIC SHOULD take on reporting node behavior for
>>     Diameter endpoints that do not support the DOIC solution.  A Diameter
>>     Agent detects that a Diameter endpoint does not support DOIC reporting
>>     node behavior when there is no OC-Supported-Features AVP in an answer
>>     message for a transaction that contained the OC-Supported-Features
>>     AVP in the request message.
>>        Note: Known issues exist if multiple sources for overload reports
>>        which apply to the same Diameter entity exist.  Reacting nodes
>>        have no way of determining the source and, as such, will treat
>>        them as coming from a single source.  Variance in sequence numbers
>>        between the two sources can then cause incorrect overload
>>        abatement treatment to be applied for indeterminate periods of
>>        time.
>>
>> You point out an interesting issue with agents taking on reporting node functionality.
>>
>> I don't, however, think that an agent that takes on reporting node functionality for a non supporting host needs to be adjacent to the host.  The important thing is that it has visibility to all of the traffic sent to the host.
>>
>> I suggest keeping the first paragraph but changing the SHOULD to a MAY.
>>
>> I also suggest changing the SHOULD to a MAY in the fourth paragraph and changing the first sentence to:
>>
>> A Diameter Agent MAY take on reporting node behavior for Diameter endpoints that do not support the DOIC solution.
> I agree with everything up to there. (Not necessarily for the reasons given, but I've been pushing for this to be MAY or non-normative for a while now :-) )
>
>
>> The Diameter Agent MUST have visibility to all traffic destined for the non supporting host in order to become the reporting node for the Diameter endpoint.
> I see the issue, but I think that answer needs more thought. It seems to disallow the case where you have a pair of agents in an active-active configuration in front of a non-supporting server, unless they sync OCS. I strongly suspect that case will be the rule, at least for telecom deployments.
SRD> I don't think it rules these deployments out, it just points out 
that they might be hard to implement.  "Has visibility" doesn't mean 
"personally handles".  There would need to be state sharing between the 
two agents for it to work correctly, but it can work.
>
> /Ben


From nobody Tue Dec 16 07:07:32 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E551A1AF2 for ; Tue, 16 Dec 2014 07:07:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSASoQv_Cvs5 for ; Tue, 16 Dec 2014 07:07:28 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B5E1A1B0C for ; Tue, 16 Dec 2014 07:07:27 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBGF7Q9M049361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2014 09:07:26 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <54904984.9080802@usdonovans.com>
Date: Tue, 16 Dec 2014 09:07:25 -0600
X-Mao-Original-Outgoing-Id: 440435245.654219-3c1a2c9edba05a4c0f72a4f3717ae31b
Content-Transfer-Encoding: quoted-printable
Message-Id: <6EF55321-C08A-411C-959D-31DC7BFE973F@nostrum.com>
References: <5486FA8B.6040503@usdonovans.com>  <54904984.9080802@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KG8Fdg4brJBUx7iafT9Z8-c213g
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested changes #9 and #10
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Dec 2014 15:07:30 -0000

> On Dec 16, 2014, at 9:02 AM, Steve Donovan  =
wrote:
>=20
>>> The Diameter Agent MUST have visibility to all traffic destined for =
the non supporting host in order to become the reporting node for the =
Diameter endpoint.
>> I see the issue, but I think that answer needs more thought. It seems =
to disallow the case where you have a pair of agents in an active-active =
configuration in front of a non-supporting server, unless they sync OCS. =
I strongly suspect that case will be the rule, at least for telecom =
deployments.
> SRD> I don't think it rules these deployments out, it just points out =
that they might be hard to implement.  "Has visibility" doesn't mean =
"personally handles".  There would need to be state sharing between the =
two agents for it to work correctly, but it can work.
>=20

For the record, I think active-active agents will be too common for us =
to require inter-agent OCS state sharing for it to work.

This problem will also exist for aggregated servers. That is also common =
place.=


From nobody Tue Dec 16 07:15:03 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B11B1A1B30 for ; Tue, 16 Dec 2014 07:14:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoVC-MP1X34S for ; Tue, 16 Dec 2014 07:14:56 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.244.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B6B21A1B44 for ; Tue, 16 Dec 2014 07:14:38 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63266 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y0tpa-0007Hb-RH; Tue, 16 Dec 2014 07:14:37 -0800
Message-ID: <54904C5A.2070502@usdonovans.com>
Date: Tue, 16 Dec 2014 09:14:34 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Campbell 
References: <5486FCBF.4000707@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152351D9@DEMUMBX014.nsn-intra.net> <54883F5C.1060603@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235675@DEMUMBX014.nsn-intra.net> <5489A416.2000403@usdonovans.com> <64AB1BC6-8D34-4DEB-B801-C5C127047C8C@nostrum.com>
In-Reply-To: <64AB1BC6-8D34-4DEB-B801-C5C127047C8C@nostrum.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5FCJS79k3K7G6-b84tfEUdJtVEA
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change @12
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Dec 2014 15:14:58 -0000

Ben,

I see a two or three options here:

1) We add a new attribution AVP and all of the text associated with it.  
This has obvious schedule implications.

2) We treat this the same way as we treated the issue with multiple 
sources of OC-OLR AVPs and add text somewhere in the draft saying that 
if agents are selecting abatement algorithms then care must be taken to 
make sure that all agents that handle traffic for the same Diameter node 
must select the same algorithm for all transactions involving that 
Diameter node.

3) Number two plus reacting node behavior statements saying that the 
reacting node SHOULD ignore overload reports for a node that has an 
active OCS if the received overload report is of a different type then 
stored in the active OCS.

I vote for number 3.

Regards,

Steve

On 12/11/14, 12:38 PM, Ben Campbell wrote:
>> On Dec 11, 2014, at 8:03 AM, Steve Donovan  wrote:
>>
>> Ulrich,
>>
>> I see your concern.  To summarize, if we have the following configuration:
>>
>>     ----A1----
>>    /          \
>>   C            S
>>    \          /
>>     ----A2----
>>
>> And A1 indicates loss in in the OC-S-F AVP in answer messages and A2 indicates rate then there is ambiguity.
>>
>> I agree, this warrants a warning statement somewhere in the document.
>>
>> If there is general agreement on this then I'll propose wording and location.
>>
> What sort of guidance should we give here? IMO, this is a worse problem than for realm reports, or at least having it for both realm and host reports makes it considerably worse than before. I think variations on this will happen for almost any Diameter network of non-trivial size.
>
> I also think it's reasonable that A1 and A2 might select different algorithms towards C. For example, lets say C, A1, and S all support rate, but A2 does not. S might select rate towards A1, but loss towards A2.
>
> If we can't handle this, I think the entire solution breaks down.
>
> I propose that the best way to handle this is to add source-attribution into OLRs, and guidance for what C should do if it gets different capabilities for the same host or realm from different paths. This _might_ also help solve the "different reports for same realm" problem and the "can't tell if an intervening agent supports DOIC" problem.
>
>
>> Steve
>>
>> On 12/11/14, 7:31 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>> Steve,
>>>   
>>> yes, it’s about capability announcement, and my concern in with announcing the selected algorithm in answer messages (while no OLRs are sent). Multiple  agents modifying the selected algorithm in the Supported-Features AVPs in answer messages may  result in ambiguity in DOIC behaviour for downstream DOIC nodes.
>>>   
>>> Ulrich
>>>   
>>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
>>> Sent: Wednesday, December 10, 2014 1:41 PM
>>> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
>>> Subject: Re: [Dime] Ulrich's suggested change @12
>>>   
>>> Ulrich,
>>>
>>> This paragraph is talking about capability announcement.  We deal with the issues related to multiple sources of overload reports already elsewhere in the document.
>>>
>>> I still do see the need for a change.
>>>
>>> Steve
>>>
>>> On 12/9/14, 10:46 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>> Steve,
>>> I agree, my comment and proposal do not hit the mark.
>>>   
>>> The intention was to say that known issues exist if there are multiple agents on multiple paths between client and server. The agents may not be able to ensure that there is no ambiguity in DOIC behaviour for the client. E.g. from the client’s point of view the answer to a first request (which was modified by agent A1) could indicate: DOIC is supported, currenty no overload, once in overload loss will be selected; and the answer to the next request (which was modified by agent A2) could indicate: DOIC is supported, some?? reduction is requested using rate. The client, however, may not be prepared for rate.
>>>   
>>> Maybe a warning note could be added to say that the agent may not always be able to ensure that there is no ambiguity.
>>>   
>>> Ulrich
>>>   
>>>   
>>>   
>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>>> Sent: Tuesday, December 09, 2014 2:45 PM
>>> To: dime@ietf.org
>>> Subject: [Dime] Ulrich's suggested change @12
>>>   
>>> Ulrich,
>>>
>>> For your suggested change #12:
>>>
>>> Section 4.1.3, last paragraph:
>>> Existing text:
>>>     When making changes to the OC-Supported-Features AVP the Diameter
>>>     Agent needs to ensure that there is no ambiguity in DOIC behavior for
>>>     both upstream and downstream DOIC nodes.
>>>   
>>> Comment: while that is true, in addition problems similar to those
>>> identified in the note in section 3.3 may result from making changes.
>>>   
>>> Proposal: Add the note:
>>>        Note: Known issues exist if multiple sources for overload reports
>>>        which apply to the same Diameter entity exist.  Reacting nodes
>>>        have no way of determining the source and, as such, will treat
>>>        them as coming from a single source.  Variance in sequence numbers
>>>        between the two sources can then cause incorrect overload
>>>        abatement treatment to be applied for indeterminate periods of
>>>        time.
>>> I don't understand how these are related.  The change to the OC-Supported-Features AVP made by the agent apply only to the transaction.  In addition, this paragraph doesn't mention overload reports.
>>>
>>> Regards,
>>>
>>> Steve
>>>
>>>
>>>
>>>   
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Tue Dec 16 07:35:47 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96EA61A1BB1 for ; Tue, 16 Dec 2014 07:35:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qGvGxProp7F for ; Tue, 16 Dec 2014 07:35:43 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A521A1BAC for ; Tue, 16 Dec 2014 07:35:43 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBGFZgUj051864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2014 09:35:42 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <54904C5A.2070502@usdonovans.com>
Date: Tue, 16 Dec 2014 09:35:41 -0600
X-Mao-Original-Outgoing-Id: 440436941.800051-ebc7063d76a6b4b0c236f5e8061ee125
Content-Transfer-Encoding: quoted-printable
Message-Id: <4C4C3C8F-3A9B-4062-98FE-F980F170AD3D@nostrum.com>
References: <5486FCBF.4000707@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152351D9@DEMUMBX014.nsn-intra.net> <54883F5C.1060603@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235675@DEMUMBX014.nsn-intra.net> <5489A416.2000403@usdonovans.com> <64AB1BC6-8D34-4DEB-B801-C5C127047C8C@nostrum.com> <54904C5A.2070502@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/F07OzZVvk6x1P_DDTN7anenC3RY
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change @12
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Dec 2014 15:35:45 -0000

> On Dec 16, 2014, at 9:14 AM, Steve Donovan  =
wrote:
>=20
> Ben,
>=20
> I see a two or three options here:
>=20
> 1) We add a new attribution AVP and all of the text associated with =
it.  This has obvious schedule implications.

Agreed that it has schedule implications. Schedule is important, but a =
workable solution is more important. (I concede that we have not yet =
established consensus that this is non-workable--see below)

>=20
> 2) We treat this the same way as we treated the issue with multiple =
sources of OC-OLR AVPs and add text somewhere in the draft saying that =
if agents are selecting abatement algorithms then care must be taken to =
make sure that all agents that handle traffic for the same Diameter node =
must select the same algorithm for all transactions involving that =
Diameter node.

On reflection, this is a more general problem than just algorithm =
choices. It's a generalization of the problem with multiple realm-report =
sources for a single realm. Basically we have a problem when you have =
more than one reporting node for a given overload scope. (The problem of =
multiple algorithms for the same "scope" would also apply to the =
multiple realm-report source issue.)

Basically, I think we've discovered the scope of the multiple =
reporting-node problem is considerably larger than we thought. That =
means we at least need to consider whether the decision to defer that =
solution is still reasonable. Remember that we made that decision at =
least partly because we thought the problem would not be that common.

>=20
> 3) Number two plus reacting node behavior statements saying that the =
reacting node SHOULD ignore overload reports for a node that has an =
active OCS if the received overload report is of a different type then =
stored in the active OCS.

Do you mean different OLR type, or different algorithm for the same OLR =
type?

>=20
> I vote for number 3.
>=20
> Regards,
>=20
> Steve
>=20
> On 12/11/14, 12:38 PM, Ben Campbell wrote:
>>> On Dec 11, 2014, at 8:03 AM, Steve Donovan =
 wrote:
>>>=20
>>> Ulrich,
>>>=20
>>> I see your concern.  To summarize, if we have the following =
configuration:
>>>=20
>>>    ----A1----
>>>   /          \
>>>  C            S
>>>   \          /
>>>    ----A2----
>>>=20
>>> And A1 indicates loss in in the OC-S-F AVP in answer messages and A2 =
indicates rate then there is ambiguity.
>>>=20
>>> I agree, this warrants a warning statement somewhere in the =
document.
>>>=20
>>> If there is general agreement on this then I'll propose wording and =
location.
>>>=20
>> What sort of guidance should we give here? IMO, this is a worse =
problem than for realm reports, or at least having it for both realm and =
host reports makes it considerably worse than before. I think variations =
on this will happen for almost any Diameter network of non-trivial size.
>>=20
>> I also think it's reasonable that A1 and A2 might select different =
algorithms towards C. For example, lets say C, A1, and S all support =
rate, but A2 does not. S might select rate towards A1, but loss towards =
A2.
>>=20
>> If we can't handle this, I think the entire solution breaks down.
>>=20
>> I propose that the best way to handle this is to add =
source-attribution into OLRs, and guidance for what C should do if it =
gets different capabilities for the same host or realm from different =
paths. This _might_ also help solve the "different reports for same =
realm" problem and the "can't tell if an intervening agent supports =
DOIC" problem.
>>=20
>>=20
>>> Steve
>>>=20
>>> On 12/11/14, 7:31 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>> Steve,
>>>>  yes, it=92s about capability announcement, and my concern in with =
announcing the selected algorithm in answer messages (while no OLRs are =
sent). Multiple  agents modifying the selected algorithm in the =
Supported-Features AVPs in answer messages may  result in ambiguity in =
DOIC behaviour for downstream DOIC nodes.
>>>>  Ulrich
>>>>  From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
>>>> Sent: Wednesday, December 10, 2014 1:41 PM
>>>> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
>>>> Subject: Re: [Dime] Ulrich's suggested change @12
>>>>  Ulrich,
>>>>=20
>>>> This paragraph is talking about capability announcement.  We deal =
with the issues related to multiple sources of overload reports already =
elsewhere in the document.
>>>>=20
>>>> I still do see the need for a change.
>>>>=20
>>>> Steve
>>>>=20
>>>> On 12/9/14, 10:46 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>> Steve,
>>>> I agree, my comment and proposal do not hit the mark.
>>>>  The intention was to say that known issues exist if there are =
multiple agents on multiple paths between client and server. The agents =
may not be able to ensure that there is no ambiguity in DOIC behaviour =
for the client. E.g. from the client=92s point of view the answer to a =
first request (which was modified by agent A1) could indicate: DOIC is =
supported, currenty no overload, once in overload loss will be selected; =
and the answer to the next request (which was modified by agent A2) =
could indicate: DOIC is supported, some?? reduction is requested using =
rate. The client, however, may not be prepared for rate.
>>>>  Maybe a warning note could be added to say that the agent may not =
always be able to ensure that there is no ambiguity.
>>>>  Ulrich
>>>>      From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext =
Steve Donovan
>>>> Sent: Tuesday, December 09, 2014 2:45 PM
>>>> To: dime@ietf.org
>>>> Subject: [Dime] Ulrich's suggested change @12
>>>>  Ulrich,
>>>>=20
>>>> For your suggested change #12:
>>>>=20
>>>> Section 4.1.3, last paragraph:
>>>> Existing text:
>>>>    When making changes to the OC-Supported-Features AVP the =
Diameter
>>>>    Agent needs to ensure that there is no ambiguity in DOIC =
behavior for
>>>>    both upstream and downstream DOIC nodes.
>>>>  Comment: while that is true, in addition problems similar to those
>>>> identified in the note in section 3.3 may result from making =
changes.
>>>>  Proposal: Add the note:
>>>>       Note: Known issues exist if multiple sources for overload =
reports
>>>>       which apply to the same Diameter entity exist.  Reacting =
nodes
>>>>       have no way of determining the source and, as such, will =
treat
>>>>       them as coming from a single source.  Variance in sequence =
numbers
>>>>       between the two sources can then cause incorrect overload
>>>>       abatement treatment to be applied for indeterminate periods =
of
>>>>       time.
>>>> I don't understand how these are related.  The change to the =
OC-Supported-Features AVP made by the agent apply only to the =
transaction.  In addition, this paragraph doesn't mention overload =
reports.
>>>>=20
>>>> Regards,
>>>>=20
>>>> Steve
>>>>=20
>>>>=20
>>>>=20
>>>> =20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>=20


From nobody Tue Dec 16 19:02:52 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF631A1A6B for ; Tue, 16 Dec 2014 19:02:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOiPe9TpPVzC for ; Tue, 16 Dec 2014 19:02:48 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F221A1A74 for ; Tue, 16 Dec 2014 19:02:48 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBH32kP7009189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2014 21:02:47 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
From: Ben Campbell 
Content-Type: text/plain; charset=us-ascii
X-Mao-Original-Outgoing-Id: 440478165.879654-962704febedd5904d064ac1b8947d23f
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Message-Id: <79E0AA6A-8F91-45FD-AE8A-EFF9D2A4E9D3@nostrum.com>
Date: Tue, 16 Dec 2014 21:02:45 -0600
To: "dime@ietf.org list" , draft-ietf-dime-ovli@tools.ietf.org
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/PPMZSUjauSvd538DGBYcb4lFgng
Subject: [Dime] DOIC WGLC: Editorial Comments
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 03:02:51 -0000

Here's some nits, editorial, and structural comments that are generally =
non-substantive. With the possible exception of comments about 2119 =
language, most of these could be ignored without consequence, but I =
think we'd have a better document if we at least thought about them:

-- General:=20

We keep referring to the DOIC "solution". I think "mechanism" is more =
appropriate. I would think of a DOIC "solution" as a deployment that =
leverages the DOIC "mechanism".

We overuse the word Diameter in front of other things. E.g. Diameter =
nodes, Diameter Agents, Diameter clients, Diameter servers, etc. This =
entire draft is about Diameter; we don't have to keep saying it. It =
tends to get awkward when we use it a lot in close proximity.

Should we put consistently quotes around "loss" when we describe the =
"loss" algorithm?

-- Requirements (2119 language section)

This is oddly placed. I'm used to seeing that after the introduction, =
either stand-alone or as part of a larger terminology section. The RFC =
editor recommends putting it as section 2.=20

-- section 2, Abatement Algorithm: "A mechanism..."

I suggest "An extensible mechanism..."

-- Section 2, Diversion:

Still needs work.  the "by selecting" phrase needs to indicate what does =
the selecting. "Path" should probably be "path or destination".

Proposed text:

"An overload abatement mechanism, where the reacting node selects =
alternate destinations or paths for for requests."

-- section 2, OCS: "Reporting and reacting node internally maintained =
state..."

I suggest "Internal state maintained by a reporting or reacting node..."

-- section 2, Realm-Routed Requests: "... does not know the host that =
will service..."

I suggest: "... does not know which host will service ..."

We should also add a comment that it may be possible to apply diversion =
to realm routed requests.

-- section 2, Throttling: " ... a Diameter Client not sending =
requests..."

I suggest " ... a Client choosing to not send requests ..."

-- section 3, 2nd paragraph:

Client, servers, and agents should not be capitalized. Should "Reporting =
node" and "Reacting node" be hyphenated?  Consider moving the last =
sentence to the start of the next paragraph.

-- section 3.1, paragraph 1: " This is made possible by adding overload =
control AVPs, the OC-OLR AVP and the OC- Supported-Features AVP, as =
optional AVPs into existing commands..."

I suggest "This is made possible by adding the optional overload control =
AVPs OC-OLR and OC-Supported-Features into existing commands."

-- section 3.1, 3rd paragraph: "Reporting nodes also include overload =
reports..."

"Reporting nodes _may_ also include overload reports..."

-- section 3.1, 4th paragraph: "Clients MAY report..."

Should not be normative in this section.

-- section 3.2, 6th paragraph: "The OC-Feature-Vector AVP will =
contain..."

"... will _always_ contain..."

-- section 3.2, 7th paragraph: " ... all answer messages to requests =
..."

suggest "... all answers to requests..."

-- section 3.2, paragraph 9: "Reporting nodes are allowed to..."

"Reporting nodes can..."

Also consider clarifying that they can change algorithms =
_between_transactions_, as long as there's no active overload condition.

-- section 3.2, paragraph 10 (starting with "The individual features..."

Consider moving this entire paragraph to earlier in the section.

-- section 3.2, paragraph 11: "The DCA mechanism must also allow..."

--> "The DCA mechanism allows..."

"... the agent updates the OC-Supported-Features..." --> " ... the agent =
can update the OC-Supported-Features..."

-- section 3.3, general:

Much of this section is redundant to stuff in the parent section. I =
suggest reducing the parent section detail, and keeping it here. (This =
may be true for subsequent children of section 3.)

-- 3.3, third paragraph:

s/ , / : /

-- 3.3, paragraph 4:

In this overview, I suggest text saying that HOST_REPORT indicates a =
host report, and just using the term "host report" the rest of the time. =
(Same for realm report)

-- 3.3, para 7: "A host-report, for instance, will generally by =
generated by tracking utilization of resources..."

I suggest "A host-report might be generated by tracking use of =
resources..."

-- 3.3, para 9: " ... are responsible for applying the overload =
abatement algorithm..."

I suggest " ... apply the abatement algorithm..."

-- 3.4, para 2: " ... the definition of new report types and the =
definition of new scopes ..."

Aren't these sort of the same thing? That is, you add new scopes by =
extending report type?

-- 3.4, para 3:

First two sentences are a bit confusing. A new reader will likely think =
they contradict, without some explanation that OC-Feature-Vector is a =
child of OC-S-F.

-- 3.4, para 4:

First sentence has already been stated more than once. No need to repeat =
here.

-- 4.1.1, Para 1: "It MAY include the OC-Feature-Vector AVP."

consider adding  ", as a sub-avp of OC-Supported-Features."

- 4.1.1, last paragraph: "This behavior is described in ..."

What is the antecedent to "this"? If it's "loss algorithm" behavior, =
then the reference to section 4.2 should not be needed.

-- 4.1.2, para 2:

It's probably worth reiterating that the reacting node may not be the =
server, and this requirement may mean inserting AVPS into answers that =
came from upstream.

-- 4.1.2, para 3: "...response messages ... "

"... _answer_ messages ... "

-- 4.1.2, para 7: "If it selects a different algorithm, it MUST...:

This is also true if it needs to announce some other feature that needs =
to be indicated.

-- 4.1.3, para 3: "... Agent MUST include OC-Supported-Features in =
request messages it receives..."

I suspect this should say "... requests that it _forwards_" or =
"_relays_".

-- 4.1.3, para 5 and 6:

Is the reporting node section limited to endpoints? If not, the these =
paragraphs effectively restate normative language about reporting node =
behavior from that section. Once we've said what a reporting node =
normatively has to do, we should just be able to say that an agent =
acting as a reporting node has all the responsibilities of a reporting =
node, and not restate the normative requirements.

-- 4.1.3, para 7:

The first MAY is a consequence (the complement) of the 2nd MAY. It =
should at least not be 2119 language, and probably can be omitted =
entirely.

-- 4.1.3, para 9, last sentence:

Does this mean an agent can only change OC-S-F in an answer if it =
changed it in the request? I don't think we want that restriction, but =
the context and "as such," seem to scope the MAY to that situation.

-- 4.1.3, para 9: "ambiguity"

I'm not sure that's is the word we want here. An agent could muck things =
up without being ambiguous. Perhaps "inconsistency"?

-- 4.2.1.1, para 1:

Do I understand correctly that the reacting node only keeps OCS for =
those combinations that it has actually received an OLR for? If so, =
that's not clear from the wording.

-- 4.2.1.2, para 1:

Likewise, the reporting node only keeps OCS for actual overload =
conditions where it sends OLRs?

-- 4.2.1.3, para 2:

Should this combination include origin-host or origin-realm? App-Id?

-- 4.2.1.3,  para 3: ... a reporting node MUST process..."

Should that be "reacting node"?

-- 4.2.1.3, para 4:=20

Paragraph does not make sense. (I think we've already discussed this one =
from Ulrich's comments).

-- 4.2.1.3, 3rd para from end: "... update the OCS entry as being =
expired."

I suggest language like " invalid" or "terminated". I take "expired" to =
mean "naturally expired", which is different from the case described =
here. There may be subtle behavior difference. (For example, a reacting =
node might choose to log "expirations" differently than "explicit =
terminations".)

-- 4.2.1.4, para 9: "... including the reduction percentage..."

I suggest "... including, for example, the reduction percentage..."

-- 4.2.1.4, para 11: " ... MUST update the sequence number ..."

I suggest s / update / increment

-- 4.2.2, 2nd to last para:

 I think we need something a bit stronger here. The endpoint needs to =
take some action that makes sense for the application. The details of =
that are beyond our scope, but the general need is not.

-- 4.2.3, para 2:

Doesn't this also need to match the scope for the request type? E.g. =
Destination realm or destination host? For example, a host report for =
host A would not match OCS for host B, even though both had the same =
report type and application id.

-- 4.2.3, paras 8 and 9:

We put the currently less favored approach first, with the favored =
approach in the following paragraph. I suggest we put the more favored =
approach first.


-- 4.2.3, last para:

An example of what we have in mind could be helpful here.


-- 4.3, para 4:

We should clarify that this is talking about mandatory to understand for =
DOIC, but not for the enclosing transaction.=20

-- 4.3, para 5:

Why is it different depending on whether the feature is an algorithm or =
not? Also, isn't this mostly redundant to the paragraph about new =
normative behavior?

-- 4.3, para 6, last sentence

This is redundant to earlier normative language in the section (assuming =
a new report type will always involve new normative behavior.)

-- 4.3, para 7, last sentence

Also redundant

-- 4.3, last para, last sentence:

It's not clear if this means section 8 of this doc, or 6733. I suggest =
putting this sentence before the subsequent one.

-- 5.1, para 4:

Convoluted paragraph. How about "How about "reporting nodes request the =
stateless reduction of the number of requests by an indicated =
percentage."=20

We should also clarify that this reduction is in comparison to what the =
reacting node otherwise would have sent, rather than what it may have =
previously sent.

-- 5.3, para 5:

Needs a sentence or paragraph to describe the 100% issue before =
describing how to back down from it.

"... following concerns are RECOMMENDED ..."

following procedures...?

-- 5.3, para 6: "... does not receive an OLR in messages sent to the =
formerly overloaded node..."

Do we mean "... does not receive an OLR in answers received from the =
formerly overloaded node..."?

-- para 6, last paragraph

Paragraph is off topic for section. It probably belongs in the =
extensibility section, or at least somewhere other than here.

-- 6.1, last para:

I think we moved this to 6.2, but forgot to delete it here.

-- 6.2:

Why did the AVP code jump to TBD6? (Also seems out of order in the =
table.)

Is it to late to rename the value to OLR_LOSS_ALGO?

-- 9.4, para 2: "A node MUST not..."

"A node MUST _NOT_ ..."

-- References:

5905 and 5729 are not cited in the document.

draft-ietf-dime-e2e-sec-req-00: Outdated version.

























From nobody Tue Dec 16 20:48:44 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7E01A1BCF for ; Tue, 16 Dec 2014 20:48:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQ68tLW48ba5 for ; Tue, 16 Dec 2014 20:48:42 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13EBC1A008A for ; Tue, 16 Dec 2014 20:48:41 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBH4meAc017797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2014 22:48:41 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
From: Ben Campbell 
Content-Type: text/plain; charset=us-ascii
X-Mao-Original-Outgoing-Id: 440484520.224279-9e329ad3ed8f41f09327d5ff0f36e8ab
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Message-Id: 
Date: Tue, 16 Dec 2014 22:48:40 -0600
To: "dime@ietf.org list" , draft-ietf-dime-ovli@tools.ietf.org
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/0-xFUUEcmEdYoYchUoyuqc0jDTE
Subject: [Dime] DOIC WGLC: Changing Algorithms
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 04:48:43 -0000

Section 4.1.2, (4th paragraph from end ) says that a reporting node =
cannot change algorithms during an active overload condition. We fail to =
say anything about when reacting nodes could change their list of =
supported algorithms. That leaves us with the question about what =
happens if a reporting node has an active OCS, and gets a new request =
with an OC-S-F that does not support the active algorithm.

The obvious answer is that reacting nodes shouldn't do that-- but I =
think there would still be legal scenarios where it could happen anyway. =
So even if we say that a single reacting node should not change its =
algorithm list while it has active OCS, we still need to handle the =
situation for reporting nodes.=


From nobody Tue Dec 16 20:55:56 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD84A1A1BDF for ; Tue, 16 Dec 2014 20:55:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovt-99okaB2N for ; Tue, 16 Dec 2014 20:55:53 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE0FE1A008A for ; Tue, 16 Dec 2014 20:55:52 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBH4tpoZ018508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2014 22:55:52 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
From: Ben Campbell 
Content-Type: text/plain; charset=us-ascii
X-Mao-Original-Outgoing-Id: 440484951.56229-afd42d8554c689a5ff01afab9c0ee56b
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Message-Id: <0AF415BD-4AA8-4A4F-942B-29DA6C9E417B@nostrum.com>
Date: Tue, 16 Dec 2014 22:55:51 -0600
To: "dime@ietf.org list" , draft-ietf-dime-ovli@tools.ietf.org
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/fPjr4txf9fvfiUnXDq2vPiqB-PA
Subject: [Dime] DOIC WGLC: duration unit
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 04:55:55 -0000

We currently define the unit for OC-Validity-Duration as milliseconds.

Section 4.2.3 says (in a note) that transit time for OLRs can be safely =
ignored. That is likely true if the validity durations can generally be =
assumed to be long in comparison to transit time. It is _not_ true if =
validity duration can be a small number of milliseconds. That could lead =
to situations where the reporting node thinks the report has expired =
before the reacting node even sees it.

Really, I don't think milliseconds are a reasonable unit here. I can't =
imagine any useful and safe application for sub-second validity =
durations, nor can I imagine it ever being useful to distinguish between =
X seconds and X + 0.001 seconds. We should choose a unit that lends =
itself to reasonable value ranges. I suggest we change it to seconds.

Thanks!

/Ben.=


From nobody Tue Dec 16 21:02:28 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404821A1BCF for ; Tue, 16 Dec 2014 21:02:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HWUo4_OgbVM for ; Tue, 16 Dec 2014 21:02:26 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46AEE1A008A for ; Tue, 16 Dec 2014 21:02:26 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBH52PAv019107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2014 23:02:25 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
From: Ben Campbell 
Content-Type: text/plain; charset=us-ascii
X-Mao-Original-Outgoing-Id: 440485345.046192-7e768d40cbd9ee4cf3fb0743f5e26060
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Message-Id: 
Date: Tue, 16 Dec 2014 23:02:25 -0600
To: "dime@ietf.org list" , draft-ietf-dime-ovli@tools.ietf.org
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-IJvHCh5RI0Fy0Fh0tTqYGcFJa0
Subject: [Dime] DOIC WGLC: Requirement for OC-Feature-Vector values
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 05:02:27 -0000

Section 4.3 requires all extensions with "new normative behaviors" to =
define a new feature bit for OC-Feature-Vector.

I still think that's too strong a requirement. If a new feature is =
backwards-compatible, then we may well not really need a feature bit. =
For example, SIP doesn't define a new feature tag for every new header. =
Also, keep in mind this is   a field of 1 bit flags. We only get 64 of =
those.

I propose we change this to say that "any non-backwards compatible" =
feature requires a new feature bit.

Thanks!

/Ben.=


From nobody Tue Dec 16 21:07:47 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047831A1BED for ; Tue, 16 Dec 2014 21:07:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13MK9aMMYT94 for ; Tue, 16 Dec 2014 21:07:41 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A8801A1BCF for ; Tue, 16 Dec 2014 21:07:41 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBH57eqM019515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2014 23:07:41 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
From: Ben Campbell 
Content-Type: text/plain; charset=us-ascii
X-Mao-Original-Outgoing-Id: 440485660.268122-4d9b8d987ab822cc8ac9bb0bbe8b00d5
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Message-Id: <94CD92E2-B801-4EC4-BECE-5C2B0788B361@nostrum.com>
Date: Tue, 16 Dec 2014 23:07:40 -0600
To: "dime@ietf.org list" , draft-ietf-dime-ovli@tools.ietf.org
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/6uwT7SJsyq9BNUQvf5ExS-zx_Tg
Subject: [Dime] DOIC WGLC: loss algorithm behavior with expiring OLRs
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 05:07:44 -0000

Section 5.3 (paragraph 7) says that, for the loss algorithm, a reacting =
node should slowly ramp back up if an OLR expires. This seems to be for =
the general case of expiring loss-algorithm OLRs, since the case of =
expiring 100% reduction OLRs was dealt with in the preceding paragraphs.

We have guidance elsewhere that a _reporting_node_ should end an =
overload condition in a controlled fashion. If both the reacting node =
and reporting node are trying to do this, you may get unexpected =
behavior. It makes sense for the reacting node to ramp up slowly from =
100% reduction, since the reporting node could not update the reduction =
percentage until expired. But for an percentage reduction that still =
allows non-trivial traffic, the reporting node should be gradually =
ramping down the reduction.

I propose we strike the entire paragraph from section 5.3.



From nobody Tue Dec 16 21:11:46 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF951A1BF0 for ; Tue, 16 Dec 2014 21:11:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qM7ZT7MRnjzR for ; Tue, 16 Dec 2014 21:11:41 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BCCE1A1BDF for ; Tue, 16 Dec 2014 21:11:41 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBH5Be1V019851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2014 23:11:41 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
From: Ben Campbell 
Content-Type: text/plain; charset=us-ascii
X-Mao-Original-Outgoing-Id: 440485900.367144-ff2d862790b8f3fd0a90a2741f6a969b
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Message-Id: <93DEBE9A-62A4-4637-9BF8-FFCD4195B115@nostrum.com>
Date: Tue, 16 Dec 2014 23:11:40 -0600
To: "dime@ietf.org list" , draft-ietf-dime-ovli@tools.ietf.org
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/S3zkGFgk0P00KsDn2koD1OpNRS4
Subject: [Dime] DOIC WGLC: Implicit values for OC-OLR
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 05:11:43 -0000

(No, this is not the general rant on implicit values you from me :-)  )

In section 6.3, paragraph 1, we have the following sentence:

" The OC-OLR AVP does not explicitly contain all information needed by =
the reacting node to decide whether a subsequent request must undergo =
abatement using the received reduction percentage."

I think this may vary by report type. For example, peer reports might =
need to include at least  some things explicitly that are implicit for =
host and realm reports. It's even different between host and realm =
reports. Therefore, I think we should remove it from this section, and =
put the specifics in the description of each report type.





From nobody Tue Dec 16 21:13:38 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FD81A1BDF for ; Tue, 16 Dec 2014 21:13:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSVM2e-fOhFM for ; Tue, 16 Dec 2014 21:13:31 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7901A1BCF for ; Tue, 16 Dec 2014 21:13:31 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBH5DUiL020008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2014 23:13:31 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
From: Ben Campbell 
Content-Type: text/plain; charset=us-ascii
X-Mao-Original-Outgoing-Id: 440486009.982025-67580e16cfa3fa74cf0ed135ad39ef25
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Message-Id: 
Date: Tue, 16 Dec 2014 23:13:30 -0600
To: "dime@ietf.org list" , draft-ietf-dime-ovli@tools.ietf.org
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-5DqPVW8Rrugeq8vy7RSpINfaD8
Subject: [Dime] DOIC WGLC: Sequence Number uniqueness
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 05:13:34 -0000

Section 6.4, paragraph 2 says the following:

" The sequence number is only required to be unique between two DOIC =
nodes."

Is that limitation useful? What about agents that pass it OLRs without =
change?

Thanks!

Ben.


From nobody Tue Dec 16 21:19:09 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C4F1A1BCF for ; Tue, 16 Dec 2014 21:19:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uq2P0xHTrPO3 for ; Tue, 16 Dec 2014 21:19:04 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68ABE1A0394 for ; Tue, 16 Dec 2014 21:19:03 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBH5J2vc020407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2014 23:19:03 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
From: Ben Campbell 
Content-Type: text/plain; charset=us-ascii
X-Mao-Original-Outgoing-Id: 440486341.990595-51544f0bbecbe17b76cc937a8bdac26f
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Message-Id: <494D7700-4468-4AB5-8F74-69273DE409AB@nostrum.com>
Date: Tue, 16 Dec 2014 23:19:02 -0600
To: "dime@ietf.org list" , draft-ietf-dime-ovli@tools.ietf.org
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/nAqGHkpArg97zR1yGT9KT45Eo9Q
Subject: [Dime] DOIC WGLC: OC-Reduction-Percentage default value
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 05:19:07 -0000

Section 6.7 says that OC-Reduction-Percentage has a default value of =
zero.

I don't think we need a "general" default for this. The loss algorithm =
says OC-Reduction-Percentage MUST be included. If some other algorithm =
uses it, and needs a default, it can define one for the context of that =
algorithm. (And we shouldn't assume every algorithm will need a default =
of zero.)

I propose we strike the default value from 6.7.=


From nobody Tue Dec 16 22:27:35 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206661A212D for ; Tue, 16 Dec 2014 22:27:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9Wkn_pJS3at for ; Tue, 16 Dec 2014 22:27:30 -0800 (PST)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9391C1A1E0C for ; Tue, 16 Dec 2014 22:27:29 -0800 (PST)
Received: by mail-lb0-f174.google.com with SMTP id 10so12038500lbg.5 for ; Tue, 16 Dec 2014 22:27:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gSrgoqrgZF51kkwLQJlXJRLlHNZ3g6V4MFmOFAmEG94=; b=R6P3lVPgJuWshYxvuQcWjrwLyGGIinCVzu7IWuAMgWaWR5tky33Q+u46odg9qvrjQS bajR2yQfkGM9ZKLlrO2MQ83MUJE8Ql1KkHld+8+7YqdHtiLPy7ma4nmntwoRRXJRU56p t1YLpqDrxyInVpQiq3d1x8dT7hnhvuGagwtE5OjlbsZAg4xiaL5r6OU0C4larmjMrvbm PyS7TxOiuqlPFS2ON397ToHqhQcAzXUddRb6eX+HL0h2/xpBnpQ2nbqYoQxBGM+8yOWL LCdv9otczPOxMQqptA1ZwlSnhyl9fuiZUiWSGh9BKWEtkWdFQo8HFOsI5JBe2sjdPeso UnOw==
X-Received: by 10.112.160.104 with SMTP id xj8mr700019lbb.62.1418797647975; Tue, 16 Dec 2014 22:27:27 -0800 (PST)
Received: from [10.17.0.23] ([83.150.126.201]) by mx.google.com with ESMTPSA id k1sm703097laf.19.2014.12.16.22.27.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 22:27:27 -0800 (PST)
Message-ID: <5491224D.1060109@gmail.com>
Date: Wed, 17 Dec 2014 08:27:25 +0200
From: Jouni Korhonen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Campbell , "dime@ietf.org list" ,  draft-ietf-dime-ovli@tools.ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2eBZsOFIXfwX7xYo_TWkWdBqqnI
Subject: Re: [Dime] DOIC WGLC: Sequence Number uniqueness
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 06:27:31 -0000

Then they pass the SN unmodified, obviously. I rather have it explicitly 
mentioned that e.g. an agent can modify the SN without that causing the 
debate whether it is correct or not. Do you have a specific case in mind 
where it could cause issues?

- jouni

12/17/2014 7:13 AM, Ben Campbell kirjoitti:
> Section 6.4, paragraph 2 says the following:
>
> " The sequence number is only required to be unique between two DOIC nodes."
>
> Is that limitation useful? What about agents that pass it OLRs without change?
>
> Thanks!
>
> Ben.
>


From nobody Tue Dec 16 22:28:53 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7A11A1E0C for ; Tue, 16 Dec 2014 22:28:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Lf0rcsTPm4H for ; Tue, 16 Dec 2014 22:28:50 -0800 (PST)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78EB01A1A73 for ; Tue, 16 Dec 2014 22:28:49 -0800 (PST)
Received: by mail-la0-f49.google.com with SMTP id hs14so12637501lab.36 for ; Tue, 16 Dec 2014 22:28:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=KJhims+nx+lgQ9r5LswSkO1sPnbBbZHZcCCPxcuFI3w=; b=g20MJ4dpOeGBgrOp0lCkZA5EWQk/vpFmV/90FiugZ5EEJ6YTlvLpllsXTMgcmbjZUo yheGhfOMEEWtN6rZhZ7PyYyoDrZo6NfcY+VUP0yfVcxysxb2L6Hl5oLXBGHhzO4BgL+g VNiCYLvxDDFlM6+AlQxUxF1lw+cR+1uWHCFg9R3U8kvmuR+rxJ6oVT5x4b/3NscqckM8 xtr1baOFcf6lwadRCYTCVQyvMzf7oe/DfUDQ6PjdkBq5uCv1v12FFatB3Kz55Jy0uADZ kMkVM9FQH4bZfyHuY1aSwA5asXByYvv1bfA0W6Dmg6uSDJ9SFJcO56yV0VIm6VNw+K5c lOBg==
X-Received: by 10.112.14.6 with SMTP id l6mr16686691lbc.91.1418797727985; Tue, 16 Dec 2014 22:28:47 -0800 (PST)
Received: from [10.17.0.23] ([83.150.126.201]) by mx.google.com with ESMTPSA id r4sm706477lar.3.2014.12.16.22.28.46 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 22:28:47 -0800 (PST)
Message-ID: <5491229D.6040709@gmail.com>
Date: Wed, 17 Dec 2014 08:28:45 +0200
From: Jouni Korhonen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: dime@ietf.org
References: <494D7700-4468-4AB5-8F74-69273DE409AB@nostrum.com>
In-Reply-To: <494D7700-4468-4AB5-8F74-69273DE409AB@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/zoklYIc_UiwKChU9A1pRP-X6VBw
Subject: Re: [Dime] DOIC WGLC: OC-Reduction-Percentage default value
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 06:28:51 -0000

OK with me.

- Jouni

12/17/2014 7:19 AM, Ben Campbell kirjoitti:
> Section 6.7 says that OC-Reduction-Percentage has a default value of zero.
>
> I don't think we need a "general" default for this. The loss algorithm says OC-Reduction-Percentage MUST be included. If some other algorithm uses it, and needs a default, it can define one for the context of that algorithm. (And we shouldn't assume every algorithm will need a default of zero.)
>
> I propose we strike the default value from 6.7.
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Tue Dec 16 22:35:40 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DCA1A0673 for ; Tue, 16 Dec 2014 22:35:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYZROflBq75x for ; Tue, 16 Dec 2014 22:35:37 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42ACB1A066B for ; Tue, 16 Dec 2014 22:35:37 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBH6ZXIP026619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2014 00:35:34 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5491224D.1060109@gmail.com>
Date: Wed, 17 Dec 2014 00:35:33 -0600
X-Mao-Original-Outgoing-Id: 440490933.557568-ebbbd7d3fd89bace288c4b193571b69b
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <5491224D.1060109@gmail.com>
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/uP0y4I3_UEsZdJUO54Lf58Xkfw8
Cc: "dime@ietf.org list" , draft-ietf-dime-ovli@tools.ietf.org
Subject: Re: [Dime] DOIC WGLC: Sequence Number uniqueness
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 06:35:39 -0000

I'm not worried so much about nodes changing it. I'm just wondering if =
that is the right scope of uniqueness. I'm not sure why "between any two =
nodes" is relevant. Or even if "uniqueness" is relevant.=20

It's a sequence number that gets incremented, not a unique ID per se.

So, here's an example: A reporting node sends both realm reports and =
host reports to the same reacting node. If the sequence number has to be =
unique between two nodes, does that mean that the realm report and host =
reports must never have the same sequence number? If we start the =
sequence at zero and increment for each change (as is recommended =
elsewhere), they are highly likely to have the same sequence number at =
some point in time.

I think the _real_ requirement is that the sequence number not repeat  =
for non-identical OLRs over the lifetime of a particular OCS instance.


> On Dec 17, 2014, at 12:27 AM, Jouni Korhonen  =
wrote:
>=20
>=20
> Then they pass the SN unmodified, obviously. I rather have it =
explicitly mentioned that e.g. an agent can modify the SN without that =
causing the debate whether it is correct or not. Do you have a specific =
case in mind where it could cause issues?
>=20
> - jouni
>=20
> 12/17/2014 7:13 AM, Ben Campbell kirjoitti:
>> Section 6.4, paragraph 2 says the following:
>>=20
>> " The sequence number is only required to be unique between two DOIC =
nodes."
>>=20
>> Is that limitation useful? What about agents that pass it OLRs =
without change?
>>=20
>> Thanks!
>>=20
>> Ben.
>>=20


From nobody Tue Dec 16 23:01:04 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78C61A6ED8 for ; Tue, 16 Dec 2014 23:01:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pms6rDHLsU8E for ; Tue, 16 Dec 2014 23:01:01 -0800 (PST)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1857F1A1EFE for ; Tue, 16 Dec 2014 23:01:01 -0800 (PST)
Received: by mail-la0-f46.google.com with SMTP id q1so12466497lam.5 for ; Tue, 16 Dec 2014 23:00:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=tRRhU+Bb6E30QqvFwjWpv3Jznxv+hYiWNE+/dQaEQJs=; b=OGbGtc0J8AXpB2P2yJAnJbX17FU4rajiT04CcAJVkgrVkaETkAT8DgXffl42SwFXin GT0EjQlf0NdCZLhq+LAwvlPuutEDMSeOsd33Sj5O0j8qwjPCJ7A9MmiHPbVkDLpl+aOR Uu93+XRPdF+Wr+T4AKbM4cW+/qCZY5c67AN146VNfvCZ4TsY5P99ORbvJY7LGUcVr0+1 E+qgbwDaRKaXFpqYMiHOIOsRa9ZY9kKvn7tK7dJ0ZegkSzkzecDonbArdJ4eywL//JEm KQg4UO3X6AQ+/6J3cG5Wq3taP1Vp7NH2tK4y+1lpn1IYOZRrhNIIUZpW2diEvRtQvatO wZNg==
X-Received: by 10.112.168.164 with SMTP id zx4mr31230562lbb.28.1418799659532;  Tue, 16 Dec 2014 23:00:59 -0800 (PST)
Received: from [10.17.0.23] ([83.150.126.201]) by mx.google.com with ESMTPSA id h7sm716466lbl.41.2014.12.16.23.00.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 23:00:57 -0800 (PST)
Message-ID: <54912A28.2060004@gmail.com>
Date: Wed, 17 Dec 2014 09:00:56 +0200
From: Jouni Korhonen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Campbell 
References:  <5491224D.1060109@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/bgVPiP0rm5Zh6B5aW1qY12DxWMA
Cc: "dime@ietf.org list" , draft-ietf-dime-ovli@tools.ietf.org
Subject: Re: [Dime] DOIC WGLC: Sequence Number uniqueness
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 07:01:03 -0000

Good point. I would be OK with that change.

- Jouni

12/17/2014 8:35 AM, Ben Campbell kirjoitti:
> I'm not worried so much about nodes changing it. I'm just wondering if that is the right scope of uniqueness. I'm not sure why "between any two nodes" is relevant. Or even if "uniqueness" is relevant.
>
> It's a sequence number that gets incremented, not a unique ID per se.
>
> So, here's an example: A reporting node sends both realm reports and host reports to the same reacting node. If the sequence number has to be unique between two nodes, does that mean that the realm report and host reports must never have the same sequence number? If we start the sequence at zero and increment for each change (as is recommended elsewhere), they are highly likely to have the same sequence number at some point in time.
>
> I think the _real_ requirement is that the sequence number not repeat  for non-identical OLRs over the lifetime of a particular OCS instance.
>
>
>> On Dec 17, 2014, at 12:27 AM, Jouni Korhonen  wrote:
>>
>>
>> Then they pass the SN unmodified, obviously. I rather have it explicitly mentioned that e.g. an agent can modify the SN without that causing the debate whether it is correct or not. Do you have a specific case in mind where it could cause issues?
>>
>> - jouni
>>
>> 12/17/2014 7:13 AM, Ben Campbell kirjoitti:
>>> Section 6.4, paragraph 2 says the following:
>>>
>>> " The sequence number is only required to be unique between two DOIC nodes."
>>>
>>> Is that limitation useful? What about agents that pass it OLRs without change?
>>>
>>> Thanks!
>>>
>>> Ben.
>>>
>


From nobody Tue Dec 16 23:03:09 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E640D1A6D3F for ; Tue, 16 Dec 2014 23:03:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2T2tih7nX20 for ; Tue, 16 Dec 2014 23:03:06 -0800 (PST)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014E91A1EFE for ; Tue, 16 Dec 2014 23:03:06 -0800 (PST)
Received: by mail-la0-f53.google.com with SMTP id gm9so12858914lab.12 for ; Tue, 16 Dec 2014 23:03:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=RvYfano1sAp3z4MAcxhjwGOiB+1FCEBbMQfuTIZtcCs=; b=CYdiU3QFJ7aCTXzUOCyk/qk3agUL6/nrOKtAq6zcNBSIwYYvgFQpFppf8lS9FVJPZp Glmwu5NQ236ZXqdDT+/bIwhswZPIWUCnhojW+66gtlqkuCsYcyfjowxlDrCDuGF/IJYy mLs20AMO8TF/wc8z7I7jVIddi4DhktlE10cBV+NSnf1A2G8t0ZJ4DNsfOMZdJytmPdSt xWF9uILXavZfoVbwJLUVeAgZaaF50fwMPUrDJgJgk6zgCxIKZ5pXUcb1A1LrbvCpUypq mP4pFHw+mm2LNenYpCLKRXKnRyTZMkgP3giuDy1PR8R9svlgr9Tb5iArcNsgiDRkdJTt tK7Q==
X-Received: by 10.152.22.199 with SMTP id g7mr39704061laf.23.1418799784435; Tue, 16 Dec 2014 23:03:04 -0800 (PST)
Received: from [10.17.0.23] ([83.150.126.201]) by mx.google.com with ESMTPSA id ri2sm719448lbb.34.2014.12.16.23.03.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 23:03:03 -0800 (PST)
Message-ID: <54912AA6.2080706@gmail.com>
Date: Wed, 17 Dec 2014 09:03:02 +0200
From: Jouni Korhonen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Campbell , "dime@ietf.org list" ,  draft-ietf-dime-ovli@tools.ietf.org
References: <93DEBE9A-62A4-4637-9BF8-FFCD4195B115@nostrum.com>
In-Reply-To: <93DEBE9A-62A4-4637-9BF8-FFCD4195B115@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ALgOdHL-69f8srXOdJKYL6GckPs
Subject: Re: [Dime] DOIC WGLC: Implicit values for OC-OLR
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 07:03:08 -0000

OK with me.

- Jouni

12/17/2014 7:11 AM, Ben Campbell kirjoitti:
> (No, this is not the general rant on implicit values you from me :-)  )
>
> In section 6.3, paragraph 1, we have the following sentence:
>
> " The OC-OLR AVP does not explicitly contain all information needed by the reacting node to decide whether a subsequent request must undergo abatement using the received reduction percentage."
>
> I think this may vary by report type. For example, peer reports might need to include at least  some things explicitly that are implicit for host and realm reports. It's even different between host and realm reports. Therefore, I think we should remove it from this section, and put the specifics in the description of each report type.
>
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Tue Dec 16 23:12:18 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8BD1A1BED for ; Tue, 16 Dec 2014 23:12:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9-3DJwtn9Wc for ; Tue, 16 Dec 2014 23:12:13 -0800 (PST)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCB751A6F21 for ; Tue, 16 Dec 2014 23:11:58 -0800 (PST)
Received: by mail-lb0-f180.google.com with SMTP id l4so12044802lbv.39 for ; Tue, 16 Dec 2014 23:11:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=HaJhx81k0IZNfNyz1DVMXibwpGkIsDUnzWQtMOr39Tg=; b=OCzKVvFdsfjwwSkmpT3eCyyO6pR3wJ8fv0Q0khQmtbQpc/LK/FWRJQZmyEw8wUAr2n Tjd1jPmfwH7m0zEsUOcXS1iISFRZrZMzBWmbNJ5kRkIVTFN5KfGqnr+oBk9XKJxfNib6 Ts4K1vTr3oeTJ7jayaPyWsSgjfQvI5NSYsSdF/7Eb2qlb0lG9DJBY6Z4EktYx0gTamu7 BVrtJn29XvvOluoYj1QtogogcyQKROLPW1H1vgHtrOv4qixYjfDUWMbzcUk9PO2LAIVA NTh+DcTD4lA3H2k9/DS1WOlXWb9ztavRoLzrWfWlmHv9XHlrdzJoEIFCVyTegpADsfNM ikkA==
X-Received: by 10.112.91.43 with SMTP id cb11mr39110755lbb.63.1418800317424; Tue, 16 Dec 2014 23:11:57 -0800 (PST)
Received: from [10.17.0.23] ([83.150.126.201]) by mx.google.com with ESMTPSA id v8sm728505lae.6.2014.12.16.23.11.55 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 23:11:56 -0800 (PST)
Message-ID: <54912CBA.8080701@gmail.com>
Date: Wed, 17 Dec 2014 09:11:54 +0200
From: Jouni Korhonen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: dime@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/i5GebyscNdpeF91p8ctjv6uMle8
Subject: Re: [Dime] DOIC WGLC: Changing Algorithms
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 07:12:15 -0000

While changing algorithm "on fly" is undesirable both reporting and 
reacting nodes need to be prepared for the situation, specifically if 
the reacting node keeps advertising multiple supported algorithms.

I think we need to flag this better in the text but stress that such 
behaviour is not desired. And in some cases not even possible to do 
cleanly (depending on the algorithm).

- Jouni

12/17/2014 6:48 AM, Ben Campbell kirjoitti:
> Section 4.1.2, (4th paragraph from end ) says that a reporting node cannot change algorithms during an active overload condition. We fail to say anything about when reacting nodes could change their list of supported algorithms. That leaves us with the question about what happens if a reporting node has an active OCS, and gets a new request with an OC-S-F that does not support the active algorithm.
>
> The obvious answer is that reacting nodes shouldn't do that-- but I think there would still be legal scenarios where it could happen anyway. So even if we say that a single reacting node should not change its algorithm list while it has active OCS, we still need to handle the situation for reporting nodes.
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Wed Dec 17 00:49:45 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8ED1A1B51 for ; Wed, 17 Dec 2014 00:49:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqIhX3dH32NC for ; Wed, 17 Dec 2014 00:49:31 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C35ED1A1B35 for ; Wed, 17 Dec 2014 00:49:30 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBH8nSnW010172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Dec 2014 08:49:28 GMT
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBH8nRKe019837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Dec 2014 09:49:27 +0100
Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 17 Dec 2014 09:49:27 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 09:49:27 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , Ben Campbell 
Thread-Topic: [Dime] Ulrich's suggested change #15
Thread-Index: AQHQE7dJhQB5e1nbwEev114RSsJu35yHeSWggAL2Z7uAAD8mAIAACZWAgAY/jwCAAU9ggIABPegg
Date: Wed, 17 Dec 2014 08:49:27 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815235AB9@DEMUMBX014.nsn-intra.net>
References: <5486FE71.70205@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235215@DEMUMBX014.nsn-intra.net> <54884137.4050209@usdonovans.com> <5AB8BAC5-3CBD-432E-9631-74DF40795844@nostrum.com> <5489A498.5070203@usdonovans.com>  <5489EFAF.8010702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152358E0@DEMUMBX014.nsn-intra.net> <549046D3.3090104@usdonovans.com>
In-Reply-To: <549046D3.3090104@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.101]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 5214
X-purgate-ID: 151667::1418806168-0000677A-86BFAAFB/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kFnXg6wVNWTAUvpkFo9KPONOHFI
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #15
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 08:49:37 -0000

Yes please.

-----Original Message-----
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
Sent: Tuesday, December 16, 2014 3:51 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
Cc: dime@ietf.org
Subject: Re: [Dime] Ulrich's suggested change #15

I'll delete the paragraph.

Do we need explicit statements for the two conditions below?

Steve


On 12/15/14, 11:56 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve, Ben,
>
> I'm fine with deleting the paragraph.
> But for my clarification please confirm that ignoring the complete set of=
 OLRs is allowed when one of these OLRs contains a report type that was not=
 advertized, or two of the OLRs contain the same report type.
>
> Regards
> Ulrich
>
>
>
> -----Original Message-----
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> Sent: Thursday, December 11, 2014 8:26 PM
> To: Ben Campbell
> Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] Ulrich's suggested change #15
>
>
> On 12/11/14, 12:51 PM, Ben Campbell wrote:
>>> On Dec 11, 2014, at 8:05 AM, Steve Donovan  w=
rote:
>>>
>>> I thought this paragraph was covering unrecognized values for all AVPs.
>> I agree that's what it covered. But I think we failed to cover the unrec=
ognized AVP case. If we don't have anything to say beyond what 6733 says, t=
hen it might not be strictly necessary, but it might still be worth saying =
that "unrecognized sub-AVPs are treated as per RFC6733".
> That is probably worth saying.
>>>    Maybe it is better to remove the paragraph entirely and make sure th=
at the definition of each AVP addresses what is done with unrecognized valu=
es.
>> Possibly. There are AVPs where there's no such thing as an unrecognized =
value. There may be AVPs where the allowed values vary by algorithm. If we =
do take that route, we probably need language here that says unrecognized v=
alues are handled as described by the AVP definition or the algorithm.
> Agreed.
>>> Steve
>>>
>>> On 12/10/14, 5:26 PM, Ben Campbell wrote:
>>>>> On Dec 10, 2014, at 6:48 AM, Steve Donovan =
 wrote:
>>>>>
>>>>> Ulrich,
>>>>>
>>>>> Actually, the wording you suggested wasn't quite right.  It should be=
:
>>>>>
>>>>>     When receiving an OC-OLR AVP with unknown values, the overload re=
port
>>>>>     SHOULD be silently discarded by reacting nodes and the event SHOU=
LD
>>>>>     be logged.
>>>>>
>>>>> It's not just about report type values but unknown values for any of =
the AVPs in the OLR.
>>>>>
>>>>> This seems like a good requirement to include in the specification to=
 ensure common behavior in reacting nodes.  I don't feel strongly about thi=
s but I would like to hear other opinions.
>>>> I think this is still not quite complete.
>>>>
>>>> If you receive a sub-AVP that you don't understand, then you should ig=
nore that sub-avp, not the whole OC-OLR AVP.  (Unless of course the unknown=
 AVP has the m-bit set.) If you receive a known sub-AVP, with a value you d=
on't understand, the behavior should be AVP specific. For Report-Type, that=
 means ignore the whole OLR.
>>>>
>>>> It's not clear to me whether the original text was about arbitrary avp=
s, or Report-Type.
>>>>
>>>>> Steve
>>>>>
>>>>> On 12/9/14, 11:04 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>>>> Hi Steve,
>>>>>>
>>>>>> I think it was pointed out by Ben that we do not specify behaviour o=
f a node for cases where it detects that another node is breaking the rule.
>>>>>> The rule is:
>>>>>>      A reporting node MUST NOT send overload reports of a type that =
has
>>>>>>      not been advertised as supported by the reacting node.
>>>>>> See section 4.2.3.
>>>>>>
>>>>>> Regards
>>>>>> Ulrich
>>>>>>
>>>>>>     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve=
 Donovan
>>>>>> Sent: Tuesday, December 09, 2014 2:52 PM
>>>>>> To: dime@ietf.org
>>>>>> Subject: [Dime] Ulrich's suggested change #15
>>>>>>
>>>>>> Ulrich,
>>>>>>
>>>>>> For your suggested change #15:
>>>>>> Section 4.2.1.3, 4th paragraph:
>>>>>> Existing text:
>>>>>>      When receiving an OC-OLR AVPs with unknown values, a reacting n=
ode
>>>>>>      SHOULD be silently discarded by reacting nodes and the event SH=
OULD
>>>>>>      be logged.
>>>>>> Comment: text is confusing. Maybe the intention was to say:
>>>>>>      When receiving an OC-OLR AVPs with an unsupported report type v=
alue, a reacting node
>>>>>>      SHOULD silently discarded the OC-OLR AVP and the event SHOULD
>>>>>>      be logged.
>>>>>> But even that is not correct.
>>>>>> Proposal: Remove the paragraph.
>>>>>> The intent was that an OC-OLR that contains unknown values should be=
 discarded.  I agree that the wording needs to be changes as you suggested.=
  I don't agree with removing the paragraph.  Can you elaborate on why you =
think it is not correct when changed as you suggested?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Steve
>>>>>>
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Wed Dec 17 06:22:10 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E621A8931 for ; Wed, 17 Dec 2014 06:22:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gt4k9z87oAiR for ; Wed, 17 Dec 2014 06:22:07 -0800 (PST)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE811A884B for ; Wed, 17 Dec 2014 06:22:07 -0800 (PST)
Received: by mail-la0-f43.google.com with SMTP id s18so13298521lam.30 for ; Wed, 17 Dec 2014 06:22:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=oAz3fNB5pJVWRj4AY/SwSAAA/xwx02u9v1orvbojHE0=; b=UP5MK/H3txz8l81yPvmL9AzC7A2/25EOH2RkiVL6DHqE8foNDMqQhaVB9K5qEHv6gT bvpai1l2+EhMp/CohFQ3nOz2O32j9gylov3DbwLkKh2F/WfRMpjzXOovKrNPJJSkAHgB 7hW8y8jLzzm+LJnJBJBk0FlJqtAwcsbG84IS+LpH7x9ocAq9f7kXWvNxzd9v3tiSIVVA uky9bQ4zLPciCTB+T3s1RWW6xbVc2Y+bVxO1njLIl0qxIegWe7Pcrk1lcPJ2wiRbiq0V 5jADEkbHCP9SBu/AwCTeC5t7WvKd0eA/DisOXu1X/aMtxLvH3yF11xzE8W/WtXX6VIAZ Ll9Q==
X-Received: by 10.152.170.194 with SMTP id ao2mr42238183lac.12.1418826125881;  Wed, 17 Dec 2014 06:22:05 -0800 (PST)
Received: from [10.17.0.23] ([83.150.126.201]) by mx.google.com with ESMTPSA id e5sm976420laf.44.2014.12.17.06.22.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Dec 2014 06:22:04 -0800 (PST)
Message-ID: <5491918B.9060602@gmail.com>
Date: Wed, 17 Dec 2014 16:22:03 +0200
From: Jouni Korhonen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org list" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/EfeOJEYWQG7tZJlK7_vEqnhrJKk
Subject: Re: [Dime] Call for WG adoption: draft-donovan-dime-doc-rate-control
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 14:22:09 -0000

Folks,

There was enough support and zero against adopting this I-D as a WG 
item. Authors, submit the document as draft-ietf-dime-*-00

- Jouni & Lionel

12/3/2014 12:12 PM, Jouni kirjoitti:
> Folks,
>
> As we discussed and agreed during the Honolulu meeting we ask for the WG adoption for draft-donovan-dime-doc-rate-control unless counter proposals show up. The "wait period" for counter proposals has been more than enough.
>
> This mail starts a two week adoption call for draft-donovan-dime-doc-rate-control as a WG Item.
>
> Express your support or disagreements in the mailing list. The call ends
> 17th Dec EOB (CET+1).
>
> - Jouni & Lionel
>


From nobody Wed Dec 17 06:22:30 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEFF1A884B for ; Wed, 17 Dec 2014 06:22:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCjzvYzZa6_i for ; Wed, 17 Dec 2014 06:22:28 -0800 (PST)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58971A897C for ; Wed, 17 Dec 2014 06:22:27 -0800 (PST)
Received: by mail-la0-f52.google.com with SMTP id hs14so13366242lab.11 for ; Wed, 17 Dec 2014 06:22:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lkdGTSP5lUeXS4GFPsUNN/IfvERu3LqbxZwWqdWLAPs=; b=mwWuap8wYWothhECVLxnGyiMjOWGWWBAeYFIAA5LZHnUc0lBLT7BmrX8RXeLCQUOIV cgSKmE6a8acTbhqgM7ay7Kz4TglX1B2icHSse95bCJoC/24YNCzMbo4nMN/oLl0bxBcb Z8wBh4OQKGhqvmDzdKNlqCK0L1PFSyZOUukmyUqY7JvD6xGe3DkmoVTzGVSb+fhWEUQa 5DUx2fhqb7NWCsU3Nb+P4DnTZ+vCGoeNXpxjgjrPHXNeYbcmOs11bxDtc/vU4xbv3H1Q GyVhzU6EPsJjKTAbgUq9IrJpKbXDGEIJOrDURs2rhWZxVfTzorkCvIm8gPlTDR1wPaFA 1qKw==
X-Received: by 10.112.210.100 with SMTP id mt4mr41082635lbc.31.1418826146388;  Wed, 17 Dec 2014 06:22:26 -0800 (PST)
Received: from [10.17.0.23] ([83.150.126.201]) by mx.google.com with ESMTPSA id x1sm977035lae.42.2014.12.17.06.22.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Dec 2014 06:22:25 -0800 (PST)
Message-ID: <5491919F.7000506@gmail.com>
Date: Wed, 17 Dec 2014 16:22:23 +0200
From: Jouni Korhonen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dime@ietf.org list" 
References: <32615952-7107-45B6-85AD-AD9F57FBE418@gmail.com>
In-Reply-To: <32615952-7107-45B6-85AD-AD9F57FBE418@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/DtxE_TOVY3A5xA3KxFHaghDJ7MM
Subject: Re: [Dime] Call for WG adoption: draft-donovan-dime-agent-overload
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 14:22:29 -0000

Folks,

There was enough support and zero against adopting this I-D as a WG 
item. Authors, submit the document as draft-ietf-dime-*-00

- Jouni & Lionel

12/3/2014 12:12 PM, Jouni kirjoitti:
> Folks,
>
> As we discussed and agreed during the Honolulu meeting we ask for the WG adoption for draft-donovan-dime-agent-overload unless counter proposals show up. The "wait period" for counter proposals has been more than enough.
>
> This mail starts a two week adoption call for draft-donovan-dime-agent-overload as a WG Item.
>
> Express your support or disagreements in the mailing list. The call ends
> 17th Dec EOB (CET+1).
>
> - Jouni & Lionel
>


From nobody Wed Dec 17 06:28:23 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF791A8A7D for ; Wed, 17 Dec 2014 06:28:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.121
X-Spam-Level: 
X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_11=1, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGkoVyam0lC9 for ; Wed, 17 Dec 2014 06:28:15 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.244.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A627C1A1AA4 for ; Wed, 17 Dec 2014 06:28:15 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53660 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y1FaH-00005T-Hh for dime@ietf.org; Wed, 17 Dec 2014 06:28:14 -0800
Message-ID: <549192FD.7060403@usdonovans.com>
Date: Wed, 17 Dec 2014 08:28:13 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: dime@ietf.org
References:  <54912CBA.8080701@gmail.com>
In-Reply-To: <54912CBA.8080701@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Ez63y9hkjUqFT32N-kiAXCb7xtc
Subject: Re: [Dime] DOIC WGLC: Changing Algorithms
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 14:28:17 -0000

The only way for a reacting node to attempt to change the algorithm is 
by removing an algorithm that had been advertised before the overload 
condition started and stopping to advertise it during an overload condition.

   C------------------>S   The reacting node advertises loss and rate
    OC-S-F(loss+rate)
   C<------------------S   The reporting node enters overload using the 
rate algorithm
           OC-S-F(rate)
           OC-OLR(...)
   C------------------>S   The reacting node stops advertising the rate 
algorithm
     OC-S-F(loss)

It is certainly conceivable that this could happen as a result of 
configuration changes at the reacting node.

I don't think, however, that we need to add any behavior changes for the 
reporting node in this case.  It is reasonable to expect a reacting node 
to continue to support an abatement algorithm it was advertising when an 
overload occurrence started for the duration of that active overload 
occurrence.  In fact, it would be detrimental to the reporting node, 
which is in an overload state, to do extra work because a reacting node 
started sending a different set of features in the OC-S-F AVP.

We already say that a reporting node must not change the algorithm 
during an active overload condition.  I propose that we strengthen this 
to include when a new set of features and abatement algorithms are 
advertised by the reporting node.  Those new features and abatement 
algorithms cannot go into effect until the existing active overload 
condition is resolved.  This would look like the following on the wire:

   C------------------>S   The reacting node advertises loss and rate
    OC-S-F(loss+rate)
   C<------------------S   The reporting node enters overload using the 
rate algorithm
           OC-S-F(rate)
           OC-OLR(...)
   C------------------>S   The reacting node stops advertising the rate 
algorithm
     OC-S-F(loss)
   C<------------------S   The reporting node ignores the new set of 
features
           OC-S-F(rate)
           OC-OLR(...)
   C------------------>S
     OC-S-F(loss)
   C<------------------S   The overload condition ends
           OC-S-F(rate)
           OC-OLR(Validity-Duration:0)
   C------------------>S   The reporting node processes the new set of 
features
     OC-S-F(loss)
   C<------------------S
           OC-S-F(loss)

Steve

On 12/17/14, 1:11 AM, Jouni Korhonen wrote:
> While changing algorithm "on fly" is undesirable both reporting and 
> reacting nodes need to be prepared for the situation, specifically if 
> the reacting node keeps advertising multiple supported algorithms.
>
> I think we need to flag this better in the text but stress that such 
> behaviour is not desired. And in some cases not even possible to do 
> cleanly (depending on the algorithm).
>
> - Jouni
>
> 12/17/2014 6:48 AM, Ben Campbell kirjoitti:
>> Section 4.1.2, (4th paragraph from end ) says that a reporting node 
>> cannot change algorithms during an active overload condition. We fail 
>> to say anything about when reacting nodes could change their list of 
>> supported algorithms. That leaves us with the question about what 
>> happens if a reporting node has an active OCS, and gets a new request 
>> with an OC-S-F that does not support the active algorithm.
>>
>> The obvious answer is that reacting nodes shouldn't do that-- but I 
>> think there would still be legal scenarios where it could happen 
>> anyway. So even if we say that a single reacting node should not 
>> change its algorithm list while it has active OCS, we still need to 
>> handle the situation for reporting nodes.
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Wed Dec 17 06:31:28 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381041A8A89 for ; Wed, 17 Dec 2014 06:31:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCI95XE1P9jg for ; Wed, 17 Dec 2014 06:31:26 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.244.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CC3A1A8A61 for ; Wed, 17 Dec 2014 06:31:25 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53666 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y1FdI-00048F-Ub for dime@ietf.org; Wed, 17 Dec 2014 06:31:24 -0800
Message-ID: <549193B8.6000603@usdonovans.com>
Date: Wed, 17 Dec 2014 08:31:20 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: dime@ietf.org
References: <0AF415BD-4AA8-4A4F-942B-29DA6C9E417B@nostrum.com>
In-Reply-To: <0AF415BD-4AA8-4A4F-942B-29DA6C9E417B@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7Kf-bbZJ1e46LWG5J9KQf5DWx0w
Subject: Re: [Dime] DOIC WGLC: duration unit
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 14:31:27 -0000

Why not change the paragraph in section 4.2.3 to indicate that the 
transit time should be taken into consideration when setting validity 
duration to a small number or milliseconds?

Steve

On 12/16/14, 10:55 PM, Ben Campbell wrote:
> We currently define the unit for OC-Validity-Duration as milliseconds.
>
> Section 4.2.3 says (in a note) that transit time for OLRs can be safely ignored. That is likely true if the validity durations can generally be assumed to be long in comparison to transit time. It is _not_ true if validity duration can be a small number of milliseconds. That could lead to situations where the reporting node thinks the report has expired before the reacting node even sees it.
>
> Really, I don't think milliseconds are a reasonable unit here. I can't imagine any useful and safe application for sub-second validity durations, nor can I imagine it ever being useful to distinguish between X seconds and X + 0.001 seconds. We should choose a unit that lends itself to reasonable value ranges. I suggest we change it to seconds.
>
> Thanks!
>
> /Ben.
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Wed Dec 17 06:40:32 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3EC1A1AB1 for ; Wed, 17 Dec 2014 06:40:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfzdOddJgAKR for ; Wed, 17 Dec 2014 06:40:30 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.244.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7E0F1A871B for ; Wed, 17 Dec 2014 06:40:30 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53698 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y1Fm7-0003F3-OZ for dime@ietf.org; Wed, 17 Dec 2014 06:40:30 -0800
Message-ID: <549195DA.6030207@usdonovans.com>
Date: Wed, 17 Dec 2014 08:40:26 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: dime@ietf.org
References:  <5491224D.1060109@gmail.com>  <54912A28.2060004@gmail.com>
In-Reply-To: <54912A28.2060004@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/yPsEnp71y6QQQ37e_9xyCO13XNA
Subject: Re: [Dime] DOIC WGLC: Sequence Number uniqueness
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 14:40:32 -0000

So the proposal is to change:

"The sequence number is only required to be unique between two DOIC nodes."

To:

"The sequence number must not repeat for non-identical OLRs over the 
lifetime of a particular OCS instance. "?

While true, I'm not sure that we even need that statement.

I propose that we just remove the first sentence and not replace it with 
anything.

Steve

On 12/17/14, 1:00 AM, Jouni Korhonen wrote:
> Good point. I would be OK with that change.
>
> - Jouni
>
> 12/17/2014 8:35 AM, Ben Campbell kirjoitti:
>> I'm not worried so much about nodes changing it. I'm just wondering 
>> if that is the right scope of uniqueness. I'm not sure why "between 
>> any two nodes" is relevant. Or even if "uniqueness" is relevant.
>>
>> It's a sequence number that gets incremented, not a unique ID per se.
>>
>> So, here's an example: A reporting node sends both realm reports and 
>> host reports to the same reacting node. If the sequence number has to 
>> be unique between two nodes, does that mean that the realm report and 
>> host reports must never have the same sequence number? If we start 
>> the sequence at zero and increment for each change (as is recommended 
>> elsewhere), they are highly likely to have the same sequence number 
>> at some point in time.
>>
>> I think the _real_ requirement is that the sequence number not 
>> repeat  for non-identical OLRs over the lifetime of a particular OCS 
>> instance.
>>
>>
>>> On Dec 17, 2014, at 12:27 AM, Jouni Korhonen 
>>>  wrote:
>>>
>>>
>>> Then they pass the SN unmodified, obviously. I rather have it 
>>> explicitly mentioned that e.g. an agent can modify the SN without 
>>> that causing the debate whether it is correct or not. Do you have a 
>>> specific case in mind where it could cause issues?
>>>
>>> - jouni
>>>
>>> 12/17/2014 7:13 AM, Ben Campbell kirjoitti:
>>>> Section 6.4, paragraph 2 says the following:
>>>>
>>>> " The sequence number is only required to be unique between two 
>>>> DOIC nodes."
>>>>
>>>> Is that limitation useful? What about agents that pass it OLRs 
>>>> without change?
>>>>
>>>> Thanks!
>>>>
>>>> Ben.
>>>>
>>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Wed Dec 17 06:42:15 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A50F1A8A9C for ; Wed, 17 Dec 2014 06:42:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WJDSKNPHF1f for ; Wed, 17 Dec 2014 06:42:10 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.244.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AB661A8A9B for ; Wed, 17 Dec 2014 06:42:10 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53703 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y1Fnk-0005NW-3I for dime@ietf.org; Wed, 17 Dec 2014 06:42:09 -0800
Message-ID: <54919640.70908@usdonovans.com>
Date: Wed, 17 Dec 2014 08:42:08 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: dime@ietf.org
References: <494D7700-4468-4AB5-8F74-69273DE409AB@nostrum.com> <5491229D.6040709@gmail.com>
In-Reply-To: <5491229D.6040709@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-Eynu4qUyWU77WfHeEBkQiOv1u8
Subject: Re: [Dime] DOIC WGLC: OC-Reduction-Percentage default value
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 14:42:11 -0000

+1
On 12/17/14, 12:28 AM, Jouni Korhonen wrote:
> OK with me.
>
> - Jouni
>
> 12/17/2014 7:19 AM, Ben Campbell kirjoitti:
>> Section 6.7 says that OC-Reduction-Percentage has a default value of 
>> zero.
>>
>> I don't think we need a "general" default for this. The loss 
>> algorithm says OC-Reduction-Percentage MUST be included. If some 
>> other algorithm uses it, and needs a default, it can define one for 
>> the context of that algorithm. (And we shouldn't assume every 
>> algorithm will need a default of zero.)
>>
>> I propose we strike the default value from 6.7.
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Wed Dec 17 06:45:46 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1021A8A8D for ; Wed, 17 Dec 2014 06:45:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SYHvxNdOuZr for ; Wed, 17 Dec 2014 06:45:42 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.244.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3101A8A8C for ; Wed, 17 Dec 2014 06:45:42 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53712 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y1Fr8-0009cp-Ev for dime@ietf.org; Wed, 17 Dec 2014 06:45:41 -0800
Message-ID: <54919712.6040007@usdonovans.com>
Date: Wed, 17 Dec 2014 08:45:38 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: dime@ietf.org
References: <94CD92E2-B801-4EC4-BECE-5C2B0788B361@nostrum.com>
In-Reply-To: <94CD92E2-B801-4EC4-BECE-5C2B0788B361@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Hro9jx5h20dNvportbVXYrxIDpk
Subject: Re: [Dime] DOIC WGLC: loss algorithm behavior with expiring OLRs
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 14:45:43 -0000

I agree.  In addition, the explanatory paragraph that follows should be 
moved to after the paragraph that discusses behavior after 100% reduction.

Steve

On 12/16/14, 11:07 PM, Ben Campbell wrote:
> Section 5.3 (paragraph 7) says that, for the loss algorithm, a reacting node should slowly ramp back up if an OLR expires. This seems to be for the general case of expiring loss-algorithm OLRs, since the case of expiring 100% reduction OLRs was dealt with in the preceding paragraphs.
>
> We have guidance elsewhere that a _reporting_node_ should end an overload condition in a controlled fashion. If both the reacting node and reporting node are trying to do this, you may get unexpected behavior. It makes sense for the reacting node to ramp up slowly from 100% reduction, since the reporting node could not update the reduction percentage until expired. But for an percentage reduction that still allows non-trivial traffic, the reporting node should be gradually ramping down the reduction.
>
> I propose we strike the entire paragraph from section 5.3.
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Wed Dec 17 06:48:23 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993B51A8A94 for ; Wed, 17 Dec 2014 06:48:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITHvDsow4Am6 for ; Wed, 17 Dec 2014 06:48:16 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.244.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78421A8AA1 for ; Wed, 17 Dec 2014 06:48:16 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53713 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y1Fte-000ClT-AF for dime@ietf.org; Wed, 17 Dec 2014 06:48:16 -0800
Message-ID: <549197AE.3080104@usdonovans.com>
Date: Wed, 17 Dec 2014 08:48:14 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: dime@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Rfjf4bFKocLd3sZ-7I-rzODGbTw
Subject: Re: [Dime] DOIC WGLC: Requirement for OC-Feature-Vector values
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 14:48:18 -0000

I'm ok with this change.

Steve

On 12/16/14, 11:02 PM, Ben Campbell wrote:
> Section 4.3 requires all extensions with "new normative behaviors" to define a new feature bit for OC-Feature-Vector.
>
> I still think that's too strong a requirement. If a new feature is backwards-compatible, then we may well not really need a feature bit. For example, SIP doesn't define a new feature tag for every new header. Also, keep in mind this is   a field of 1 bit flags. We only get 64 of those.
>
> I propose we change this to say that "any non-backwards compatible" feature requires a new feature bit.
>
> Thanks!
>
> /Ben.
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Wed Dec 17 08:26:57 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF3E1A8B84 for ; Wed, 17 Dec 2014 08:26:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlK4P5o1oJgl for ; Wed, 17 Dec 2014 08:26:52 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.244.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2752C1A8AF6 for ; Wed, 17 Dec 2014 08:26:52 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53821 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y1HR2-0007wI-29 for dime@ietf.org; Wed, 17 Dec 2014 08:26:51 -0800
Message-ID: <5491AEC7.8070307@usdonovans.com>
Date: Wed, 17 Dec 2014 10:26:47 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: dime@ietf.org
References: <79E0AA6A-8F91-45FD-AE8A-EFF9D2A4E9D3@nostrum.com>
In-Reply-To: <79E0AA6A-8F91-45FD-AE8A-EFF9D2A4E9D3@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/afEUES6Erl_Dul2e-JHHG43iNHw
Subject: Re: [Dime] DOIC WGLC: Editorial Comments
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 16:26:55 -0000

On 12/16/14, 9:02 PM, Ben Campbell wrote:
> Here's some nits, editorial, and structural comments that are generally non-substantive. With the possible exception of comments about 2119 language, most of these could be ignored without consequence, but I think we'd have a better document if we at least thought about them:
>
> -- General:
>
> We keep referring to the DOIC "solution". I think "mechanism" is more appropriate. I would think of a DOIC "solution" as a deployment that leverages the DOIC "mechanism".
SRD> I don't see an issue here, as long as we are consistent.
>
> We overuse the word Diameter in front of other things. E.g. Diameter nodes, Diameter Agents, Diameter clients, Diameter servers, etc. This entire draft is about Diameter; we don't have to keep saying it. It tends to get awkward when we use it a lot in close proximity.
SRD> This was done based on feedback from Benoit.  We are being 
explicit.  If there are paragraphs where it is particularly cumbersome, 
please point out those paragraphs and we can try to make them less 
cumbersome.
>
> Should we put consistently quotes around "loss" when we describe the "loss" algorithm?
>
> -- Requirements (2119 language section)
>
> This is oddly placed. I'm used to seeing that after the introduction, either stand-alone or as part of a larger terminology section. The RFC editor recommends putting it as section 2.
SRD> Ok.
>
> -- section 2, Abatement Algorithm: "A mechanism..."
>
> I suggest "An extensible mechanism..."
SRD> Ok.
>
> -- Section 2, Diversion:
>
> Still needs work.  the "by selecting" phrase needs to indicate what does the selecting. "Path" should probably be "path or destination".
>
> Proposed text:
>
> "An overload abatement mechanism, where the reacting node selects alternate destinations or paths for for requests."
SRD> I'm ok with this wording.
>
> -- section 2, OCS: "Reporting and reacting node internally maintained state..."
>
> I suggest "Internal state maintained by a reporting or reacting node..."
SRD> Ok.
>
> -- section 2, Realm-Routed Requests: "... does not know the host that will service..."
>
> I suggest: "... does not know which host will service ..."
SRD> Ok.
>
> We should also add a comment that it may be possible to apply diversion to realm routed requests.
SRD> Where?
>
> -- section 2, Throttling: " ... a Diameter Client not sending requests..."
>
> I suggest " ... a Client choosing to not send requests ..."
SRD> A Diameter Client...
>
> -- section 3, 2nd paragraph:
>
> Client, servers, and agents should not be capitalized. Should "Reporting node" and "Reacting node" be hyphenated?  Consider moving the last sentence to the start of the next paragraph.
SRD> The capitalization of Diameter Clients, Diameter Servers and 
Diameter agents was Benoit's suggestion to make it explicit what is 
being referred to.  I don't see the need for hyphenation in this 
context.  I'm ok with moving the sentence.
>
> -- section 3.1, paragraph 1: " This is made possible by adding overload control AVPs, the OC-OLR AVP and the OC- Supported-Features AVP, as optional AVPs into existing commands..."
>
> I suggest "This is made possible by adding the optional overload control AVPs OC-OLR and OC-Supported-Features into existing commands."
SRD> OK.
>
> -- section 3.1, 3rd paragraph: "Reporting nodes also include overload reports..."
>
> "Reporting nodes _may_ also include overload reports..."
SRD> OK.
>
> -- section 3.1, 4th paragraph: "Clients MAY report..."
>
> Should not be normative in this section.
SRD> Agreed.
>
> -- section 3.2, 6th paragraph: "The OC-Feature-Vector AVP will contain..."
>
> "... will _always_ contain..."
SRD> Ok.
>
> -- section 3.2, 7th paragraph: " ... all answer messages to requests ..."
>
> suggest "... all answers to requests..."
SRD> Ok.
>
> -- section 3.2, paragraph 9: "Reporting nodes are allowed to..."
>
> "Reporting nodes can..."
SRD> Ok.
>
> Also consider clarifying that they can change algorithms _between_transactions_, as long as there's no active overload condition.
>
> -- section 3.2, paragraph 10 (starting with "The individual features..."
>
> Consider moving this entire paragraph to earlier in the section.
>
> -- section 3.2, paragraph 11: "The DCA mechanism must also allow..."
SRD> This paragraph looks redundant.  I suggest removing it.
>
> --> "The DCA mechanism allows..."
>
> "... the agent updates the OC-Supported-Features..." --> " ... the agent can update the OC-Supported-Features..."
SRD> Ok.
>
> -- section 3.3, general:
>
> Much of this section is redundant to stuff in the parent section. I suggest reducing the parent section detail, and keeping it here. (This may be true for subsequent children of section 3.)
SRD> Do you have specific suggestions?
>
> -- 3.3, third paragraph:
>
> s/ , / : /
SRD> I don't agree.  The commas are there because it is a list.
>
> -- 3.3, paragraph 4:
>
> In this overview, I suggest text saying that HOST_REPORT indicates a host report, and just using the term "host report" the rest of the time. (Same for realm report)
SRD> Why?
>
> -- 3.3, para 7: "A host-report, for instance, will generally by generated by tracking utilization of resources..."
>
> I suggest "A host-report might be generated by tracking use of resources..."
SRD> OK.
>
> -- 3.3, para 9: " ... are responsible for applying the overload abatement algorithm..."
>
> I suggest " ... apply the abatement algorithm..."
SRD> Ok.
>
> -- 3.4, para 2: " ... the definition of new report types and the definition of new scopes ..."
>
> Aren't these sort of the same thing? That is, you add new scopes by extending report type?
SRD> Can't you have a how report that applies only to sessions on that host?
>
> -- 3.4, para 3:
>
> First two sentences are a bit confusing. A new reader will likely think they contradict, without some explanation that OC-Feature-Vector is a child of OC-S-F.
SRD> They seam clear to me.  Do you have a suggested clarification?
>
> -- 3.4, para 4:
>
> First sentence has already been stated more than once. No need to repeat here.
SRD> The first sentence is there to provide context for the second 
sentence.
>
> -- 4.1.1, Para 1: "It MAY include the OC-Feature-Vector AVP."
>
> consider adding  ", as a sub-avp of OC-Supported-Features."
SRD> OK
>
> - 4.1.1, last paragraph: "This behavior is described in ..."
>
> What is the antecedent to "this"? If it's "loss algorithm" behavior, then the reference to section 4.2 should not be needed.
SRD> Agreed.
>
> -- 4.1.2, para 2:
>
> It's probably worth reiterating that the reacting node may not be the server, and this requirement may mean inserting AVPS into answers that came from upstream.
SRD> I don't see the need.  Do you have suggested wording?
>
> -- 4.1.2, para 3: "...response messages ... "
>
> "... _answer_ messages ..."
SRD> OK.
>
> -- 4.1.2, para 7: "If it selects a different algorithm, it MUST...:
>
> This is also true if it needs to announce some other feature that needs to be indicated.
SRD> This paragraph is talking specifically about algorithms and is 
needed because the AVP is optional.  Are you suggesting another 
sentence, another paragraph?  I'm guessing that the case you talk about 
is already covered elsewhere.
>
> -- 4.1.3, para 3: "... Agent MUST include OC-Supported-Features in request messages it receives..."
>
> I suspect this should say "... requests that it _forwards_" or "_relays_".
SRD> To differentiate between the requests that it rejects.  Ok, I think 
relays is the better word.
>
> -- 4.1.3, para 5 and 6:
>
> Is the reporting node section limited to endpoints? If not, the these paragraphs effectively restate normative language about reporting node behavior from that section. Once we've said what a reporting node normatively has to do, we should just be able to say that an agent acting as a reporting node has all the responsibilities of a reporting node, and not restate the normative requirements.
SRD> I'm ok with this but it feels like more than an editorial change to me.
>
> -- 4.1.3, para 7:
>
> The first MAY is a consequence (the complement) of the 2nd MAY. It should at least not be 2119 language, and probably can be omitted entirely.
SRD> Do you have suggested wording?
>
> -- 4.1.3, para 9, last sentence:
>
> Does this mean an agent can only change OC-S-F in an answer if it changed it in the request? I don't think we want that restriction, but the context and "as such," seem to scope the MAY to that situation.
SRD> I don't read it that way.  The first sentence is describing one 
reason why an agent might change OC-S-F.  It doesn't say it is the only 
reason.
>
> -- 4.1.3, para 9: "ambiguity"
>
> I'm not sure that's is the word we want here. An agent could muck things up without being ambiguous. Perhaps "inconsistency"?
SRD> The point is that the reacting nodes and reporting nodes must 
unambiguously know what to do.  I think ambiguous is the right word.
>
> -- 4.2.1.1, para 1:
>
> Do I understand correctly that the reacting node only keeps OCS for those combinations that it has actually received an OLR for? If so, that's not clear from the wording.
SRD> Do you have suggested wording?
>
> -- 4.2.1.2, para 1:
>
> Likewise, the reporting node only keeps OCS for actual overload conditions where it sends OLRs?
SRD> Do you have suggested wording?
>
> -- 4.2.1.3, para 2:
>
> Should this combination include origin-host or origin-realm? App-Id?
SRD> I don't understand this.
>
> -- 4.2.1.3,  para 3: ... a reporting node MUST process..."
>
> Should that be "reacting node"?
SRD> Yes.
>
> -- 4.2.1.3, para 4:
>
> Paragraph does not make sense. (I think we've already discussed this one from Ulrich's comments).
SRD> Yes, this is addressed already.
>
> -- 4.2.1.3, 3rd para from end: "... update the OCS entry as being expired."
>
> I suggest language like " invalid" or "terminated". I take "expired" to mean "naturally expired", which is different from the case described here. There may be subtle behavior difference. (For example, a reacting node might choose to log "expirations" differently than "explicit terminations".)
SRD> For the context of this specification I think expired works.  
Implementations can differentiate types of expired if they have a 
reason.  Nothing here prevents that.
>
> -- 4.2.1.4, para 9: "... including the reduction percentage..."
>
> I suggest "... including, for example, the reduction percentage..."
SRD> OK.
>
> -- 4.2.1.4, para 11: " ... MUST update the sequence number ..."
>
> I suggest s / update / increment
SRD> OK.
>
> -- 4.2.2, 2nd to last para:
>
>   I think we need something a bit stronger here. The endpoint needs to take some action that makes sense for the application. The details of that are beyond our scope, but the general need is not.
SRD> We cannot enforce application behavior in a Diameter 
specification.   I don't see the need for anything more .  Do you have 
suggested wording?
>
> -- 4.2.3, para 2:
>
> Doesn't this also need to match the scope for the request type? E.g. Destination realm or destination host? For example, a host report for host A would not match OCS for host B, even though both had the same report type and application id.
SRD> I guess this matters when an agent is the reporting node.
>
> -- 4.2.3, paras 8 and 9:
>
> We put the currently less favored approach first, with the favored approach in the following paragraph. I suggest we put the more favored approach first.
SRD> OK.
>
>
> -- 4.2.3, last para:
>
> An example of what we have in mind could be helpful here.
SRD> I'm open to suggested wording...
>
>
> -- 4.3, para 4:
>
> We should clarify that this is talking about mandatory to understand for DOIC, but not for the enclosing transaction.
SRD> i'm not clear on what you are suggesting.  Do you have suggested 
wording?
>
> -- 4.3, para 5:
>
> Why is it different depending on whether the feature is an algorithm or not? Also, isn't this mostly redundant to the paragraph about new normative behavior?
SRD> I agree, this paragraph can be removed.
>
> -- 4.3, para 6, last sentence
>
> This is redundant to earlier normative language in the section (assuming a new report type will always involve new normative behavior.)
SRD> I agree, the last sentence can be removed.
>
> -- 4.3, para 7, last sentence
>
> Also redundant
SRD> Agreed.
>
> -- 4.3, last para, last sentence:
>
> It's not clear if this means section 8 of this doc, or 6733. I suggest putting this sentence before the subsequent one.
SRD> OK.
>
> -- 5.1, para 4:
>
> Convoluted paragraph. How about "How about "reporting nodes request the stateless reduction of the number of requests by an indicated percentage."
SRD> Ok.
>
> We should also clarify that this reduction is in comparison to what the reacting node otherwise would have sent, rather than what it may have previously sent.
SRD> Isn't this already covered?  Do you have suggested wording?
>
> -- 5.3, para 5:
>
> Needs a sentence or paragraph to describe the 100% issue before describing how to back down from it.
SRD> It's discussed earlier in the document.  I'm ok with adding it 
again.  Do you have suggested wording?
>
> "... following concerns are RECOMMENDED ..."
>
> following procedures...?
SRD> OK.
>
> -- 5.3, para 6: "... does not receive an OLR in messages sent to the formerly overloaded node..."
>
> Do we mean "... does not receive an OLR in answers received from the formerly overloaded node..."?
SRD> Agreed.
>
> -- para 6, last paragraph
>
> Paragraph is off topic for section. It probably belongs in the extensibility section, or at least somewhere other than here.
SRD> Do you mean section 6? This isn't about extensibility but about how 
Diameter applications integrate DOIC.  It probably belongs in the intro 
or overview sections.
>
> -- 6.1, last para:
>
> I think we moved this to 6.2, but forgot to delete it here.
SRD> Yup, already addressed as part of Ulrich's comments.
>
> -- 6.2:
>
> Why did the AVP code jump to TBD6? (Also seems out of order in the table.)
SRD> Historical reasons.  Doesn't matter, the real values will be filled 
in eventually.
>
> Is it to late to rename the value to OLR_LOSS_ALGO?
SRD> Yes. :-)
>
> -- 9.4, para 2: "A node MUST not..."
>
> "A node MUST _NOT_ ..."
SRD> Ok.
>
> -- References:
>
> 5905 and 5729 are not cited in the document.
SRD> Ok.
>
> draft-ietf-dime-e2e-sec-req-00: Outdated version.
SRD> Ok.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Wed Dec 17 08:28:53 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21D71A8BC3 for ; Wed, 17 Dec 2014 08:28:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gx57MYXJ9u7R for ; Wed, 17 Dec 2014 08:28:47 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02751A8BC0 for ; Wed, 17 Dec 2014 08:28:46 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBHGSjHp080547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2014 10:28:46 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <549192FD.7060403@usdonovans.com>
Date: Wed, 17 Dec 2014 10:28:45 -0600
X-Mao-Original-Outgoing-Id: 440526524.362778-2f645816acc168ad07422fcbe45acbfc
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <54912CBA.8080701@gmail.com> <549192FD.7060403@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Sf4ru3vQYD4JaKtlun3dbuHnA3g
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: Changing Algorithms
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 16:28:50 -0000

I seem to be completely failing at describing the issue.

Imagine this picture:

C1---
        \
          -------A------S
	 /
C2---

Now, assume S is overloaded. Consider two cases:

1) C1 and C2 support DOIC. A either doesn't support it, or does support =
it but passes DCA unchanged. Is this flow legal? (I assume "yes", since =
"no" would have some nasty implications about mixed capability =
environments.)

C1 ------>A------>S
(loss + rate)
C1 <------A<------S
                   (rate)
                   (OLR-rate)
C2------->A------>S
(loss)
C2<------A<-------S
                   (loss)
                   (OLR-loss)


2) Now assume C1 and C2 do not support DOIC, but A does, but A changes =
config mid way through. According to your proposal, I _think_ it would =
work like this (see difference in last answer)

C1 ------>A------>S
                 (loss + rate)
C1 <------A<------S
                   (rate)
                   (OLR-rate)
C2------->A------>S
                    (loss)
C2<------A<-------S
                   (_rate_)
                   (OLR-rate)


The problem is, S cannot tell the difference between the two flows. In =
the first case, there are two separate reacting nodes with different =
capabilities. In the second case there's a single reacting node with =
changing capabilities. But from S's perspective, the requests look =
exactly the same.

(At this point, some one will point out that in the first case, the =
OC-S-F difference can correspond to different Origin-Host values, and in =
case 2 they do not. Maybe S can infer the difference from that. To that, =
I say assume now that C1 and C2 are really agents, and all the traffic =
is coming from a single client behind them. The issue would be the same, =
but Origin-Host would never change.)



> On Dec 17, 2014, at 8:28 AM, Steve Donovan  =
wrote:
>=20
> The only way for a reacting node to attempt to change the algorithm is =
by removing an algorithm that had been advertised before the overload =
condition started and stopping to advertise it during an overload =
condition.
>=20
>  C------------------>S   The reacting node advertises loss and rate
>   OC-S-F(loss+rate)
>  C<------------------S   The reporting node enters overload using the =
rate algorithm
>          OC-S-F(rate)
>          OC-OLR(...)
>  C------------------>S   The reacting node stops advertising the rate =
algorithm
>    OC-S-F(loss)
>=20
> It is certainly conceivable that this could happen as a result of =
configuration changes at the reacting node.
>=20
> I don't think, however, that we need to add any behavior changes for =
the reporting node in this case.  It is reasonable to expect a reacting =
node to continue to support an abatement algorithm it was advertising =
when an overload occurrence started for the duration of that active =
overload occurrence.  In fact, it would be detrimental to the reporting =
node, which is in an overload state, to do extra work because a reacting =
node started sending a different set of features in the OC-S-F AVP.
>=20
> We already say that a reporting node must not change the algorithm =
during an active overload condition.  I propose that we strengthen this =
to include when a new set of features and abatement algorithms are =
advertised by the reporting node.  Those new features and abatement =
algorithms cannot go into effect until the existing active overload =
condition is resolved.  This would look like the following on the wire:
>=20
>  C------------------>S   The reacting node advertises loss and rate
>   OC-S-F(loss+rate)
>  C<------------------S   The reporting node enters overload using the =
rate algorithm
>          OC-S-F(rate)
>          OC-OLR(...)
>  C------------------>S   The reacting node stops advertising the rate =
algorithm
>    OC-S-F(loss)
>  C<------------------S   The reporting node ignores the new set of =
features
>          OC-S-F(rate)
>          OC-OLR(...)
>  C------------------>S
>    OC-S-F(loss)
>  C<------------------S   The overload condition ends
>          OC-S-F(rate)
>          OC-OLR(Validity-Duration:0)
>  C------------------>S   The reporting node processes the new set of =
features
>    OC-S-F(loss)
>  C<------------------S
>          OC-S-F(loss)
>=20
> Steve
>=20
> On 12/17/14, 1:11 AM, Jouni Korhonen wrote:
>> While changing algorithm "on fly" is undesirable both reporting and =
reacting nodes need to be prepared for the situation, specifically if =
the reacting node keeps advertising multiple supported algorithms.
>>=20
>> I think we need to flag this better in the text but stress that such =
behaviour is not desired. And in some cases not even possible to do =
cleanly (depending on the algorithm).
>>=20
>> - Jouni
>>=20
>> 12/17/2014 6:48 AM, Ben Campbell kirjoitti:
>>> Section 4.1.2, (4th paragraph from end ) says that a reporting node =
cannot change algorithms during an active overload condition. We fail to =
say anything about when reacting nodes could change their list of =
supported algorithms. That leaves us with the question about what =
happens if a reporting node has an active OCS, and gets a new request =
with an OC-S-F that does not support the active algorithm.
>>>=20
>>> The obvious answer is that reacting nodes shouldn't do that-- but I =
think there would still be legal scenarios where it could happen anyway. =
So even if we say that a single reacting node should not change its =
algorithm list while it has active OCS, we still need to handle the =
situation for reporting nodes.
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Dec 17 08:31:00 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F871A8B84 for ; Wed, 17 Dec 2014 08:30:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yzeJit71RU9 for ; Wed, 17 Dec 2014 08:30:53 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04A4C1A8F3C for ; Wed, 17 Dec 2014 08:30:47 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBHGUkjf080710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2014 10:30:46 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <549193B8.6000603@usdonovans.com>
Date: Wed, 17 Dec 2014 10:30:45 -0600
X-Mao-Original-Outgoing-Id: 440526645.094785-135b7a8b8710d8e2b59652913769245e
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <0AF415BD-4AA8-4A4F-942B-29DA6C9E417B@nostrum.com> <549193B8.6000603@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/vp4PK-O_sZQe0VtXO9-wKxc4Tr0
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: duration unit
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 16:30:55 -0000

Why would you ever set validity duration to a small number of =
milliseconds?

I think asking nodes to take transit time into consideration adds =
considerable complexity.

> On Dec 17, 2014, at 8:31 AM, Steve Donovan  =
wrote:
>=20
> Why not change the paragraph in section 4.2.3 to indicate that the =
transit time should be taken into consideration when setting validity =
duration to a small number or milliseconds?
>=20
> Steve
>=20
> On 12/16/14, 10:55 PM, Ben Campbell wrote:
>> We currently define the unit for OC-Validity-Duration as =
milliseconds.
>>=20
>> Section 4.2.3 says (in a note) that transit time for OLRs can be =
safely ignored. That is likely true if the validity durations can =
generally be assumed to be long in comparison to transit time. It is =
_not_ true if validity duration can be a small number of milliseconds. =
That could lead to situations where the reporting node thinks the report =
has expired before the reacting node even sees it.
>>=20
>> Really, I don't think milliseconds are a reasonable unit here. I =
can't imagine any useful and safe application for sub-second validity =
durations, nor can I imagine it ever being useful to distinguish between =
X seconds and X + 0.001 seconds. We should choose a unit that lends =
itself to reasonable value ranges. I suggest we change it to seconds.
>>=20
>> Thanks!
>>=20
>> /Ben.
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Dec 17 08:31:34 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF8D1A8BBD for ; Wed, 17 Dec 2014 08:31:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxacgdH0o-7T for ; Wed, 17 Dec 2014 08:31:30 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F7C41A8B84 for ; Wed, 17 Dec 2014 08:31:30 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBHGUkjg080710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2014 10:31:30 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <549195DA.6030207@usdonovans.com>
Date: Wed, 17 Dec 2014 10:31:30 -0600
X-Mao-Original-Outgoing-Id: 440526689.901631-36fecb2cd0ef001e236629e76d3fd62e
Content-Transfer-Encoding: quoted-printable
Message-Id: <3B788EE3-C248-43F6-AB00-AC90492FBE8C@nostrum.com>
References:  <5491224D.1060109@gmail.com>  <54912A28.2060004@gmail.com> <549195DA.6030207@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/d8qtV70LYcPUMcM37mVbBTypMN8
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: Sequence Number uniqueness
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 16:31:32 -0000

> On Dec 17, 2014, at 8:40 AM, Steve Donovan  =
wrote:
>=20
> So the proposal is to change:
>=20
> "The sequence number is only required to be unique between two DOIC =
nodes."
>=20
> To:
>=20
> "The sequence number must not repeat for non-identical OLRs over the =
lifetime of a particular OCS instance. "?
>=20
> While true, I'm not sure that we even need that statement.
>=20
> I propose that we just remove the first sentence and not replace it =
with anything.

I'm okay with that. I think the other bits are sufficiently explained =
elsewhere.


From nobody Wed Dec 17 08:43:57 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC961A8AF5 for ; Wed, 17 Dec 2014 08:43:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRALyBVGyqmY for ; Wed, 17 Dec 2014 08:43:50 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.244.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680791A1BC0 for ; Wed, 17 Dec 2014 08:43:43 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53838 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y1HhL-0004kW-NS; Wed, 17 Dec 2014 08:43:42 -0800
Message-ID: <5491B2BB.30709@usdonovans.com>
Date: Wed, 17 Dec 2014 10:43:39 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Campbell 
References: <0AF415BD-4AA8-4A4F-942B-29DA6C9E417B@nostrum.com> <549193B8.6000603@usdonovans.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/OGvNw9yqP35VO2Kv7sqsAjAFxIU
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: duration unit
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 16:43:52 -0000

On 12/17/14, 10:30 AM, Ben Campbell wrote:
> Why would you ever set validity duration to a small number of milliseconds?
Why not?
>
> I think asking nodes to take transit time into consideration adds considerable complexity.
I don't see that saying that validity duration values less then the RTT 
should be avoided is adding considerable complexity.
>
>> On Dec 17, 2014, at 8:31 AM, Steve Donovan  wrote:
>>
>> Why not change the paragraph in section 4.2.3 to indicate that the transit time should be taken into consideration when setting validity duration to a small number or milliseconds?
>>
>> Steve
>>
>> On 12/16/14, 10:55 PM, Ben Campbell wrote:
>>> We currently define the unit for OC-Validity-Duration as milliseconds.
>>>
>>> Section 4.2.3 says (in a note) that transit time for OLRs can be safely ignored. That is likely true if the validity durations can generally be assumed to be long in comparison to transit time. It is _not_ true if validity duration can be a small number of milliseconds. That could lead to situations where the reporting node thinks the report has expired before the reacting node even sees it.
>>>
>>> Really, I don't think milliseconds are a reasonable unit here. I can't imagine any useful and safe application for sub-second validity durations, nor can I imagine it ever being useful to distinguish between X seconds and X + 0.001 seconds. We should choose a unit that lends itself to reasonable value ranges. I suggest we change it to seconds.
>>>
>>> Thanks!
>>>
>>> /Ben.
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Wed Dec 17 09:26:19 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC941A1BF3 for ; Wed, 17 Dec 2014 09:26:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vld3u13c83HN for ; Wed, 17 Dec 2014 09:26:14 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.244.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 929631A1BEE for ; Wed, 17 Dec 2014 09:26:14 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53869 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y1IMV-0001iY-Ad; Wed, 17 Dec 2014 09:26:13 -0800
Message-ID: <5491BCB3.30608@usdonovans.com>
Date: Wed, 17 Dec 2014 11:26:11 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Campbell 
References:  <54912CBA.8080701@gmail.com> <549192FD.7060403@usdonovans.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qcYLpVNTyysydO9ybQ5kgi_WASE
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: Changing Algorithms
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 17:26:16 -0000

Ben,

The value of the Origin-Host matters greatly here.  In both cases, what 
S needs to know is if there is a reacting node for traffic coming from 
C1 and if there is a reacting node for traffic coming from C2.

More inline.

Steve


On 12/17/14, 10:28 AM, Ben Campbell wrote:
> I seem to be completely failing at describing the issue.
>
> Imagine this picture:
>
> C1---
>          \
>            -------A------S
> 	 /
> C2---
>
> Now, assume S is overloaded. Consider two cases:
>
> 1) C1 and C2 support DOIC. A either doesn't support it, or does support it but passes DCA unchanged. Is this flow legal? (I assume "yes", since "no" would have some nasty implications about mixed capability environments.)
>
> C1 ------>A------>S
> (loss + rate)
> C1 <------A<------S
>                     (rate)
>                     (OLR-rate)
> C2------->A------>S
> (loss)
> C2<------A<-------S
>                     (loss)
>                     (OLR-loss)
SRD> Yes, this is legal and is no different then the case where C1 and 
C2 are directly connected to S.
>
> 2) Now assume C1 and C2 do not support DOIC, but A does, but A changes config mid way through. According to your proposal, I _think_ it would work like this (see difference in last answer)
>
> C1 ------>A------>S
>                   (loss + rate)
> C1 <------A<------S
>                     (rate)
>                     (OLR-rate)
> C2------->A------>S
>                      (loss)
> C2<------A<-------S
>                     (_rate_)
>                     (OLR-rate)
SRD> In this case S would need to select loss because the reacting node 
for C2 only supports loss.  It doesn't matter if the reacting node for 
C2 resides in the element called C2 or if it resides in A.  All S needs 
to know is if there is a reacting node for traffic originated by C2.  S 
differentiates the source of the traffic using the Origin-Host AVP in 
the request messages.
>
>
> The problem is, S cannot tell the difference between the two flows. In the first case, there are two separate reacting nodes with different capabilities. In the second case there's a single reacting node with changing capabilities. But from S's perspective, the requests look exactly the same.
SRD> There are two separate reacting nodes in the second case as well.  
They are "virtual" reacting nodes that happen to reside in A.
>
> (At this point, some one will point out that in the first case, the OC-S-F difference can correspond to different Origin-Host values, and in case 2 they do not. Maybe S can infer the difference from that. To that, I say assume now that C1 and C2 are really agents, and all the traffic is coming from a single client behind them. The issue would be the same, but Origin-Host would never change.)
>
>
>
>> On Dec 17, 2014, at 8:28 AM, Steve Donovan  wrote:
>>
>> The only way for a reacting node to attempt to change the algorithm is by removing an algorithm that had been advertised before the overload condition started and stopping to advertise it during an overload condition.
>>
>>   C------------------>S   The reacting node advertises loss and rate
>>    OC-S-F(loss+rate)
>>   C<------------------S   The reporting node enters overload using the rate algorithm
>>           OC-S-F(rate)
>>           OC-OLR(...)
>>   C------------------>S   The reacting node stops advertising the rate algorithm
>>     OC-S-F(loss)
>>
>> It is certainly conceivable that this could happen as a result of configuration changes at the reacting node.
>>
>> I don't think, however, that we need to add any behavior changes for the reporting node in this case.  It is reasonable to expect a reacting node to continue to support an abatement algorithm it was advertising when an overload occurrence started for the duration of that active overload occurrence.  In fact, it would be detrimental to the reporting node, which is in an overload state, to do extra work because a reacting node started sending a different set of features in the OC-S-F AVP.
>>
>> We already say that a reporting node must not change the algorithm during an active overload condition.  I propose that we strengthen this to include when a new set of features and abatement algorithms are advertised by the reporting node.  Those new features and abatement algorithms cannot go into effect until the existing active overload condition is resolved.  This would look like the following on the wire:
>>
>>   C------------------>S   The reacting node advertises loss and rate
>>    OC-S-F(loss+rate)
>>   C<------------------S   The reporting node enters overload using the rate algorithm
>>           OC-S-F(rate)
>>           OC-OLR(...)
>>   C------------------>S   The reacting node stops advertising the rate algorithm
>>     OC-S-F(loss)
>>   C<------------------S   The reporting node ignores the new set of features
>>           OC-S-F(rate)
>>           OC-OLR(...)
>>   C------------------>S
>>     OC-S-F(loss)
>>   C<------------------S   The overload condition ends
>>           OC-S-F(rate)
>>           OC-OLR(Validity-Duration:0)
>>   C------------------>S   The reporting node processes the new set of features
>>     OC-S-F(loss)
>>   C<------------------S
>>           OC-S-F(loss)
>>
>> Steve
>>
>> On 12/17/14, 1:11 AM, Jouni Korhonen wrote:
>>> While changing algorithm "on fly" is undesirable both reporting and reacting nodes need to be prepared for the situation, specifically if the reacting node keeps advertising multiple supported algorithms.
>>>
>>> I think we need to flag this better in the text but stress that such behaviour is not desired. And in some cases not even possible to do cleanly (depending on the algorithm).
>>>
>>> - Jouni
>>>
>>> 12/17/2014 6:48 AM, Ben Campbell kirjoitti:
>>>> Section 4.1.2, (4th paragraph from end ) says that a reporting node cannot change algorithms during an active overload condition. We fail to say anything about when reacting nodes could change their list of supported algorithms. That leaves us with the question about what happens if a reporting node has an active OCS, and gets a new request with an OC-S-F that does not support the active algorithm.
>>>>
>>>> The obvious answer is that reacting nodes shouldn't do that-- but I think there would still be legal scenarios where it could happen anyway. So even if we say that a single reacting node should not change its algorithm list while it has active OCS, we still need to handle the situation for reporting nodes.
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Wed Dec 17 09:29:00 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5C31A1BC0 for ; Wed, 17 Dec 2014 09:28:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MWFyWNbKKdX for ; Wed, 17 Dec 2014 09:28:57 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E7C1A1BD6 for ; Wed, 17 Dec 2014 09:28:57 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBHHSuGG086134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2014 11:28:56 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5491B2BB.30709@usdonovans.com>
Date: Wed, 17 Dec 2014 11:28:55 -0600
X-Mao-Original-Outgoing-Id: 440530135.642317-5c95618f8be270ff391a1fbd3e9af34f
Content-Transfer-Encoding: quoted-printable
Message-Id: <3543DB65-DFC1-4ADE-8808-7B931F325F92@nostrum.com>
References: <0AF415BD-4AA8-4A4F-942B-29DA6C9E417B@nostrum.com> <549193B8.6000603@usdonovans.com>  <5491B2BB.30709@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/JUsTfbvCcBnTXsyHhkd4beu59sg
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: duration unit
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 17:28:59 -0000

> On Dec 17, 2014, at 10:43 AM, Steve Donovan  =
wrote:
>=20
>=20
> On 12/17/14, 10:30 AM, Ben Campbell wrote:
>> Why would you ever set validity duration to a small number of =
milliseconds?
> Why not?

Because it's false precision. It's more likely to be harmful than =
useful. The precision of a value should be appropriate for it's the =
precision of its measurement. Inappropriate precision leads to bad =
decisions. [1]

The validity duration means one of two things, or a combination of them: =
1) I estimate that I will be overloaded for roughly X time and/or 2) I =
will tell you if I am still overloaded, with sufficient notice you can =
reasonably act on it before the expiration.

(Of the two, I think 2) is the more realistic.)

For 1: If we think we can estimate how long it you are likely to be =
overloaded down to sub-second precision, I'd like to see the magic =
prediction algorithm.

For 2: Sub second validity durations require multiple updates a second =
to refresh the OLR state. That creates a _lot_ of almost certainly =
useless work for the reacting node.


[1] http://en.wikipedia.org/wiki/False_precision


>>=20
>> I think asking nodes to take transit time into consideration adds =
considerable complexity.
> I don't see that saying that validity duration values less then the =
RTT should be avoided is adding considerable complexity.

We currently don't have a requirement to estimate RTT, other than "we =
assume it's not crazy big." This would add one.

>>=20
>>> On Dec 17, 2014, at 8:31 AM, Steve Donovan =
 wrote:
>>>=20
>>> Why not change the paragraph in section 4.2.3 to indicate that the =
transit time should be taken into consideration when setting validity =
duration to a small number or milliseconds?
>>>=20
>>> Steve
>>>=20
>>> On 12/16/14, 10:55 PM, Ben Campbell wrote:
>>>> We currently define the unit for OC-Validity-Duration as =
milliseconds.
>>>>=20
>>>> Section 4.2.3 says (in a note) that transit time for OLRs can be =
safely ignored. That is likely true if the validity durations can =
generally be assumed to be long in comparison to transit time. It is =
_not_ true if validity duration can be a small number of milliseconds. =
That could lead to situations where the reporting node thinks the report =
has expired before the reacting node even sees it.
>>>>=20
>>>> Really, I don't think milliseconds are a reasonable unit here. I =
can't imagine any useful and safe application for sub-second validity =
durations, nor can I imagine it ever being useful to distinguish between =
X seconds and X + 0.001 seconds. We should choose a unit that lends =
itself to reasonable value ranges. I suggest we change it to seconds.
>>>>=20
>>>> Thanks!
>>>>=20
>>>> /Ben.
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>=20


From nobody Wed Dec 17 09:41:59 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8151A6F17 for ; Wed, 17 Dec 2014 09:41:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASaugpOj__rc for ; Wed, 17 Dec 2014 09:41:55 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE921A6EE7 for ; Wed, 17 Dec 2014 09:41:55 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBHHfsh2087247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2014 11:41:55 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5491BCB3.30608@usdonovans.com>
Date: Wed, 17 Dec 2014 11:41:54 -0600
X-Mao-Original-Outgoing-Id: 440530914.331482-0f7d50adfd880a20d688c4f84ed37dbd
Content-Transfer-Encoding: quoted-printable
Message-Id: <0EEB7B88-CEEF-4A33-BD61-E4378F0D054D@nostrum.com>
References:  <54912CBA.8080701@gmail.com> <549192FD.7060403@usdonovans.com>  <5491BCB3.30608@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/8B6Fx7mUx2KN-r8oZNl6PhUpdYM
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: Changing Algorithms
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 17:41:58 -0000

Okay, new picture:

    =20
> On Dec 17, 2014, at 11:26 AM, Steve Donovan  =
wrote:
>=20
> Ben,
>=20
> The value of the Origin-Host matters greatly here.  In both cases, =
what S needs to know is if there is a reacting node for traffic coming =
from C1 and if there is a reacting node for traffic coming from C2.

There is no assumption in the draft right now that we have a correlation =
between reacting nodes and clients. That might be required for =
client-targed OLRs, but we don't have those yet.

Consider a different picture. In this case, C never supports DOIC. the =
reacting node role happens either at A1/A2 or at A3, depending on which =
flow you look at.

        A1---
       /         \
C --             -------A3------S
       \         /
         A2---

Now, assume the same flows, but substitute A1 for C1, A2, for C2, and A3 =
for A. All requests now have the same origin-host.

Before you say this is unrealistic: The issue is the same for any =
situation where one client can send traffic across multiple agents to =
the same destination. It doesn't matter if there is one or a million.


>=20
> More inline.
>=20
> Steve
>=20
>=20
> On 12/17/14, 10:28 AM, Ben Campbell wrote:
>> I seem to be completely failing at describing the issue.
>>=20
>> Imagine this picture:
>>=20
>> C1---
>>         \
>>           -------A------S
>> 	 /
>> C2---
>>=20
>> Now, assume S is overloaded. Consider two cases:
>>=20
>> 1) C1 and C2 support DOIC. A either doesn't support it, or does =
support it but passes DCA unchanged. Is this flow legal? (I assume =
"yes", since "no" would have some nasty implications about mixed =
capability environments.)
>>=20
>> C1 ------>A------>S
>> (loss + rate)
>> C1 <------A<------S
>>                    (rate)
>>                    (OLR-rate)
>> C2------->A------>S
>> (loss)
>> C2<------A<-------S
>>                    (loss)
>>                    (OLR-loss)
> SRD> Yes, this is legal and is no different then the case where C1 and =
C2 are directly connected to S.
>>=20
>> 2) Now assume C1 and C2 do not support DOIC, but A does, but A =
changes config mid way through. According to your proposal, I _think_ it =
would work like this (see difference in last answer)
>>=20
>> C1 ------>A------>S
>>                  (loss + rate)
>> C1 <------A<------S
>>                    (rate)
>>                    (OLR-rate)
>> C2------->A------>S
>>                     (loss)
>> C2<------A<-------S
>>                    (_rate_)
>>                    (OLR-rate)
> SRD> In this case S would need to select loss because the reacting =
node for C2 only supports loss.  It doesn't matter if the reacting node =
for C2 resides in the element called C2 or if it resides in A.  All S =
needs to know is if there is a reacting node for traffic originated by =
C2.  S differentiates the source of the traffic using the Origin-Host =
AVP in the request messages.

If we expect a separate reacting node "instance" for each request =
origin-host, we need to say so. But it still doesn't work for the single =
client example.


>>=20
>>=20
>> The problem is, S cannot tell the difference between the two flows. =
In the first case, there are two separate reacting nodes with different =
capabilities. In the second case there's a single reacting node with =
changing capabilities. But from S's perspective, the requests look =
exactly the same.
> SRD> There are two separate reacting nodes in the second case as well. =
 They are "virtual" reacting nodes that happen to reside in A.

Where does the draft say or even imply that? It would make sense if we =
were asking for different abatement for C1 and C2, but we are not.  But =
in any case, consider the single client example above.

>>=20
>> (At this point, some one will point out that in the first case, the =
OC-S-F difference can correspond to different Origin-Host values, and in =
case 2 they do not. Maybe S can infer the difference from that. To that, =
I say assume now that C1 and C2 are really agents, and all the traffic =
is coming from a single client behind them. The issue would be the same, =
but Origin-Host would never change.)
>>=20
>>=20
>>=20
>>> On Dec 17, 2014, at 8:28 AM, Steve Donovan =
 wrote:
>>>=20
>>> The only way for a reacting node to attempt to change the algorithm =
is by removing an algorithm that had been advertised before the overload =
condition started and stopping to advertise it during an overload =
condition.
>>>=20
>>>  C------------------>S   The reacting node advertises loss and rate
>>>   OC-S-F(loss+rate)
>>>  C<------------------S   The reporting node enters overload using =
the rate algorithm
>>>          OC-S-F(rate)
>>>          OC-OLR(...)
>>>  C------------------>S   The reacting node stops advertising the =
rate algorithm
>>>    OC-S-F(loss)
>>>=20
>>> It is certainly conceivable that this could happen as a result of =
configuration changes at the reacting node.
>>>=20
>>> I don't think, however, that we need to add any behavior changes for =
the reporting node in this case.  It is reasonable to expect a reacting =
node to continue to support an abatement algorithm it was advertising =
when an overload occurrence started for the duration of that active =
overload occurrence.  In fact, it would be detrimental to the reporting =
node, which is in an overload state, to do extra work because a reacting =
node started sending a different set of features in the OC-S-F AVP.
>>>=20
>>> We already say that a reporting node must not change the algorithm =
during an active overload condition.  I propose that we strengthen this =
to include when a new set of features and abatement algorithms are =
advertised by the reporting node.  Those new features and abatement =
algorithms cannot go into effect until the existing active overload =
condition is resolved.  This would look like the following on the wire:
>>>=20
>>>  C------------------>S   The reacting node advertises loss and rate
>>>   OC-S-F(loss+rate)
>>>  C<------------------S   The reporting node enters overload using =
the rate algorithm
>>>          OC-S-F(rate)
>>>          OC-OLR(...)
>>>  C------------------>S   The reacting node stops advertising the =
rate algorithm
>>>    OC-S-F(loss)
>>>  C<------------------S   The reporting node ignores the new set of =
features
>>>          OC-S-F(rate)
>>>          OC-OLR(...)
>>>  C------------------>S
>>>    OC-S-F(loss)
>>>  C<------------------S   The overload condition ends
>>>          OC-S-F(rate)
>>>          OC-OLR(Validity-Duration:0)
>>>  C------------------>S   The reporting node processes the new set of =
features
>>>    OC-S-F(loss)
>>>  C<------------------S
>>>          OC-S-F(loss)
>>>=20
>>> Steve
>>>=20
>>> On 12/17/14, 1:11 AM, Jouni Korhonen wrote:
>>>> While changing algorithm "on fly" is undesirable both reporting and =
reacting nodes need to be prepared for the situation, specifically if =
the reacting node keeps advertising multiple supported algorithms.
>>>>=20
>>>> I think we need to flag this better in the text but stress that =
such behaviour is not desired. And in some cases not even possible to do =
cleanly (depending on the algorithm).
>>>>=20
>>>> - Jouni
>>>>=20
>>>> 12/17/2014 6:48 AM, Ben Campbell kirjoitti:
>>>>> Section 4.1.2, (4th paragraph from end ) says that a reporting =
node cannot change algorithms during an active overload condition. We =
fail to say anything about when reacting nodes could change their list =
of supported algorithms. That leaves us with the question about what =
happens if a reporting node has an active OCS, and gets a new request =
with an OC-S-F that does not support the active algorithm.
>>>>>=20
>>>>> The obvious answer is that reacting nodes shouldn't do that-- but =
I think there would still be legal scenarios where it could happen =
anyway. So even if we say that a single reacting node should not change =
its algorithm list while it has active OCS, we still need to handle the =
situation for reporting nodes.
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>=20


From nobody Wed Dec 17 10:34:59 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6141A1B98 for ; Wed, 17 Dec 2014 10:34:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNzcqBljsiJ0 for ; Wed, 17 Dec 2014 10:34:54 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.244.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7123C1A0055 for ; Wed, 17 Dec 2014 10:34:54 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54190 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y1JQv-0005Pd-SG; Wed, 17 Dec 2014 10:34:52 -0800
Message-ID: <5491CCC9.3090809@usdonovans.com>
Date: Wed, 17 Dec 2014 12:34:49 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Campbell 
References:  <54912CBA.8080701@gmail.com> <549192FD.7060403@usdonovans.com>  <5491BCB3.30608@usdonovans.com> <0EEB7B88-CEEF-4A33-BD61-E4378F0D054D@nostrum.com>
In-Reply-To: <0EEB7B88-CEEF-4A33-BD61-E4378F0D054D@nostrum.com>
Content-Type: multipart/alternative; boundary="------------080607050504080904040303"
X-OutGoing-Spam-Status: No, score=0.6
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/DG-6-ZlkWYuuuxv7s_GxN0R2lec
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: Changing Algorithms
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 18:34:57 -0000

This is a multi-part message in MIME format.
--------------080607050504080904040303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


On 12/17/14, 11:41 AM, Ben Campbell wrote:
> Okay, new picture:
>
>       
>> On Dec 17, 2014, at 11:26 AM, Steve Donovan  wrote:
>>
>> Ben,
>>
>> The value of the Origin-Host matters greatly here.  In both cases, what S needs to know is if there is a reacting node for traffic coming from C1 and if there is a reacting node for traffic coming from C2.
> There is no assumption in the draft right now that we have a correlation between reacting nodes and clients. That might be required for client-targed OLRs, but we don't have those yet.
>
> Consider a different picture. In this case, C never supports DOIC. the reacting node role happens either at A1/A2 or at A3, depending on which flow you look at.
>
>          A1---
>         /         \
> C --             -------A3------S
>         \         /
>           A2---
>
> Now, assume the same flows, but substitute A1 for C1, A2, for C2, and A3 for A. All requests now have the same origin-host.
>
> Before you say this is unrealistic: The issue is the same for any situation where one client can send traffic across multiple agents to the same destination. It doesn't matter if there is one or a million.

SRD> Yes, this is nasty.  With attribution S can detect the scenario.  
I'm not sure what it does once it selects it.  This can be addressed to 
some degree by adding a deployment recommendation that  all agents 
taking on reacting node functionality for a single endpoint  select the 
same algorithm.

>
>
>> More inline.
>>
>> Steve
>>
>>
>> On 12/17/14, 10:28 AM, Ben Campbell wrote:
>>> I seem to be completely failing at describing the issue.
>>>
>>> Imagine this picture:
>>>
>>> C1---
>>>          \
>>>            -------A------S
>>> 	 /
>>> C2---
>>>
>>> Now, assume S is overloaded. Consider two cases:
>>>
>>> 1) C1 and C2 support DOIC. A either doesn't support it, or does support it but passes DCA unchanged. Is this flow legal? (I assume "yes", since "no" would have some nasty implications about mixed capability environments.)
>>>
>>> C1 ------>A------>S
>>> (loss + rate)
>>> C1 <------A<------S
>>>                     (rate)
>>>                     (OLR-rate)
>>> C2------->A------>S
>>> (loss)
>>> C2<------A<-------S
>>>                     (loss)
>>>                     (OLR-loss)
>> SRD> Yes, this is legal and is no different then the case where C1 and C2 are directly connected to S.
>>> 2) Now assume C1 and C2 do not support DOIC, but A does, but A changes config mid way through. According to your proposal, I _think_ it would work like this (see difference in last answer)
>>>
>>> C1 ------>A------>S
>>>                   (loss + rate)
>>> C1 <------A<------S
>>>                     (rate)
>>>                     (OLR-rate)
>>> C2------->A------>S
>>>                      (loss)
>>> C2<------A<-------S
>>>                     (_rate_)
>>>                     (OLR-rate)
>> SRD> In this case S would need to select loss because the reacting node for C2 only supports loss.  It doesn't matter if the reacting node for C2 resides in the element called C2 or if it resides in A.  All S needs to know is if there is a reacting node for traffic originated by C2.  S differentiates the source of the traffic using the Origin-Host AVP in the request messages.
> If we expect a separate reacting node "instance" for each request origin-host, we need to say so. But it still doesn't work for the single client example.
SRD> We can certainly make it explicit.
>
>
>>>
>>> The problem is, S cannot tell the difference between the two flows. In the first case, there are two separate reacting nodes with different capabilities. In the second case there's a single reacting node with changing capabilities. But from S's perspective, the requests look exactly the same.
>> SRD> There are two separate reacting nodes in the second case as well.  They are "virtual" reacting nodes that happen to reside in A.
> Where does the draft say or even imply that? It would make sense if we were asking for different abatement for C1 and C2, but we are not.  But in any case, consider the single client example above.
SRD> Section 4.1.3, second paragraph - "A Diameter Agent SHOULD take on 
reacting node behavior for Diameter endpoints that do not support the 
DOIC solution."
>
>>> (At this point, some one will point out that in the first case, the OC-S-F difference can correspond to different Origin-Host values, and in case 2 they do not. Maybe S can infer the difference from that. To that, I say assume now that C1 and C2 are really agents, and all the traffic is coming from a single client behind them. The issue would be the same, but Origin-Host would never change.)
>>>
>>>
>>>
>>>> On Dec 17, 2014, at 8:28 AM, Steve Donovan  wrote:
>>>>
>>>> The only way for a reacting node to attempt to change the algorithm is by removing an algorithm that had been advertised before the overload condition started and stopping to advertise it during an overload condition.
>>>>
>>>>   C------------------>S   The reacting node advertises loss and rate
>>>>    OC-S-F(loss+rate)
>>>>   C<------------------S   The reporting node enters overload using the rate algorithm
>>>>           OC-S-F(rate)
>>>>           OC-OLR(...)
>>>>   C------------------>S   The reacting node stops advertising the rate algorithm
>>>>     OC-S-F(loss)
>>>>
>>>> It is certainly conceivable that this could happen as a result of configuration changes at the reacting node.
>>>>
>>>> I don't think, however, that we need to add any behavior changes for the reporting node in this case.  It is reasonable to expect a reacting node to continue to support an abatement algorithm it was advertising when an overload occurrence started for the duration of that active overload occurrence.  In fact, it would be detrimental to the reporting node, which is in an overload state, to do extra work because a reacting node started sending a different set of features in the OC-S-F AVP.
>>>>
>>>> We already say that a reporting node must not change the algorithm during an active overload condition.  I propose that we strengthen this to include when a new set of features and abatement algorithms are advertised by the reporting node.  Those new features and abatement algorithms cannot go into effect until the existing active overload condition is resolved.  This would look like the following on the wire:
>>>>
>>>>   C------------------>S   The reacting node advertises loss and rate
>>>>    OC-S-F(loss+rate)
>>>>   C<------------------S   The reporting node enters overload using the rate algorithm
>>>>           OC-S-F(rate)
>>>>           OC-OLR(...)
>>>>   C------------------>S   The reacting node stops advertising the rate algorithm
>>>>     OC-S-F(loss)
>>>>   C<------------------S   The reporting node ignores the new set of features
>>>>           OC-S-F(rate)
>>>>           OC-OLR(...)
>>>>   C------------------>S
>>>>     OC-S-F(loss)
>>>>   C<------------------S   The overload condition ends
>>>>           OC-S-F(rate)
>>>>           OC-OLR(Validity-Duration:0)
>>>>   C------------------>S   The reporting node processes the new set of features
>>>>     OC-S-F(loss)
>>>>   C<------------------S
>>>>           OC-S-F(loss)
>>>>
>>>> Steve
>>>>
>>>> On 12/17/14, 1:11 AM, Jouni Korhonen wrote:
>>>>> While changing algorithm "on fly" is undesirable both reporting and reacting nodes need to be prepared for the situation, specifically if the reacting node keeps advertising multiple supported algorithms.
>>>>>
>>>>> I think we need to flag this better in the text but stress that such behaviour is not desired. And in some cases not even possible to do cleanly (depending on the algorithm).
>>>>>
>>>>> - Jouni
>>>>>
>>>>> 12/17/2014 6:48 AM, Ben Campbell kirjoitti:
>>>>>> Section 4.1.2, (4th paragraph from end ) says that a reporting node cannot change algorithms during an active overload condition. We fail to say anything about when reacting nodes could change their list of supported algorithms. That leaves us with the question about what happens if a reporting node has an active OCS, and gets a new request with an OC-S-F that does not support the active algorithm.
>>>>>>
>>>>>> The obvious answer is that reacting nodes shouldn't do that-- but I think there would still be legal scenarios where it could happen anyway. So even if we say that a single reacting node should not change its algorithm list while it has active OCS, we still need to handle the situation for reporting nodes.
>>>>>> _______________________________________________
>>>>>> DiME mailing list
>>>>>> DiME@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>>
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>


--------------080607050504080904040303
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    
On 12/17/14, 11:41 AM, Ben Campbell
      wrote:

    

    

      
Okay, new picture:

     


      

        
On Dec 17, 2014, at 11:26 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

Ben,

The value of the Origin-Host matters greatly here.  In both cases, what S needs to know is if there is a reacting node for traffic coming from C1 and if there is a reacting node for traffic coming from C2.


      

      
There is no assumption in the draft right now that we have a correlation between reacting nodes and clients. That might be required for client-targed OLRs, but we don't have those yet.

Consider a different picture. In this case, C never supports DOIC. the reacting node role happens either at A1/A2 or at A3, depending on which flow you look at.

        A1---
       /         \
C --             -------A3------S
       \         /
         A2---

Now, assume the same flows, but substitute A1 for C1, A2, for C2, and A3 for A. All requests now have the same origin-host.

Before you say this is unrealistic: The issue is the same for any situation where one client can send traffic across multiple agents to the same destination. It doesn't matter if there is one or a million.

    

    

    SRD> Yes, this is nasty.  With attribution S can detect the
    scenario.  I'm not sure what it does once it selects it.  This can
    be addressed to some degree by adding a deployment recommendation
    that  all agents taking on reacting node functionality for a single
    endpoint  select the same algorithm.  

    

    

      




      

        
More inline.

Steve


On 12/17/14, 10:28 AM, Ben Campbell wrote:


        

          
I seem to be completely failing at describing the issue.

Imagine this picture:

C1---
        \
          -------A------S
	 /
C2---

Now, assume S is overloaded. Consider two cases:

1) C1 and C2 support DOIC. A either doesn't support it, or does support it but passes DCA unchanged. Is this flow legal? (I assume "yes", since "no" would have some nasty implications about mixed capability environments.)

C1 ------>A------>S
(loss + rate)
C1 <------A<------S
                   (rate)
                   (OLR-rate)
C2------->A------>S
(loss)
C2<------A<-------S
                   (loss)
                   (OLR-loss)


        

        
SRD> Yes, this is legal and is no different then the case where C1 and C2 are directly connected to S.


        

          
2) Now assume C1 and C2 do not support DOIC, but A does, but A changes config mid way through. According to your proposal, I _think_ it would work like this (see difference in last answer)

C1 ------>A------>S
                 (loss + rate)
C1 <------A<------S
                   (rate)
                   (OLR-rate)
C2------->A------>S
                    (loss)
C2<------A<-------S
                   (_rate_)
                   (OLR-rate)


        

        
SRD> In this case S would need to select loss because the reacting node for C2 only supports loss.  It doesn't matter if the reacting node for C2 resides in the element called C2 or if it resides in A.  All S needs to know is if there is a reacting node for traffic originated by C2.  S differentiates the source of the traffic using the Origin-Host AVP in the request messages.


      

      
If we expect a separate reacting node "instance" for each request origin-host, we need to say so. But it still doesn't work for the single client example.

    

    SRD> We can certainly make it explicit.

    

      




      

        

          

The problem is, S cannot tell the difference between the two flows. In the first case, there are two separate reacting nodes with different capabilities. In the second case there's a single reacting node with changing capabilities. But from S's perspective, the requests look exactly the same.


        

        
SRD> There are two separate reacting nodes in the second case as well.  They are "virtual" reacting nodes that happen to reside in A.


      

      
Where does the draft say or even imply that? It would make sense if we were asking for different abatement for C1 and C2, but we are not.  But in any case, consider the single client example above.

    

    SRD> Section 4.1.3, second paragraph - "A Diameter Agent SHOULD
    take on reacting node behavior for Diameter endpoints that do not
    support the DOIC solution."
    
    

      



      

        

          
(At this point, some one will point out that in the first case, the OC-S-F difference can correspond to different Origin-Host values, and in case 2 they do not. Maybe S can infer the difference from that. To that, I say assume now that C1 and C2 are really agents, and all the traffic is coming from a single client behind them. The issue would be the same, but Origin-Host would never change.)





          

            
On Dec 17, 2014, at 8:28 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

The only way for a reacting node to attempt to change the algorithm is by removing an algorithm that had been advertised before the overload condition started and stopping to advertise it during an overload condition.

 C------------------>S   The reacting node advertises loss and rate
  OC-S-F(loss+rate)
 C<------------------S   The reporting node enters overload using the rate algorithm
         OC-S-F(rate)
         OC-OLR(...)
 C------------------>S   The reacting node stops advertising the rate algorithm
   OC-S-F(loss)

It is certainly conceivable that this could happen as a result of configuration changes at the reacting node.

I don't think, however, that we need to add any behavior changes for the reporting node in this case.  It is reasonable to expect a reacting node to continue to support an abatement algorithm it was advertising when an overload occurrence started for the duration of that active overload occurrence.  In fact, it would be detrimental to the reporting node, which is in an overload state, to do extra work because a reacting node started sending a different set of features in the OC-S-F AVP.

We already say that a reporting node must not change the algorithm during an active overload condition.  I propose that we strengthen this to include when a new set of features and abatement algorithms are advertised by the reporting node.  Those new features and abatement algorithms cannot go into effect until the existing active overload condition is resolved.  This would look like the following on the wire:

 C------------------>S   The reacting node advertises loss and rate
  OC-S-F(loss+rate)
 C<------------------S   The reporting node enters overload using the rate algorithm
         OC-S-F(rate)
         OC-OLR(...)
 C------------------>S   The reacting node stops advertising the rate algorithm
   OC-S-F(loss)
 C<------------------S   The reporting node ignores the new set of features
         OC-S-F(rate)
         OC-OLR(...)
 C------------------>S
   OC-S-F(loss)
 C<------------------S   The overload condition ends
         OC-S-F(rate)
         OC-OLR(Validity-Duration:0)
 C------------------>S   The reporting node processes the new set of features
   OC-S-F(loss)
 C<------------------S
         OC-S-F(loss)

Steve

On 12/17/14, 1:11 AM, Jouni Korhonen wrote:


            

              
While changing algorithm "on fly" is undesirable both reporting and reacting nodes need to be prepared for the situation, specifically if the reacting node keeps advertising multiple supported algorithms.

I think we need to flag this better in the text but stress that such behaviour is not desired. And in some cases not even possible to do cleanly (depending on the algorithm).

- Jouni

12/17/2014 6:48 AM, Ben Campbell kirjoitti:


              

                
Section 4.1.2, (4th paragraph from end ) says that a reporting node cannot change algorithms during an active overload condition. We fail to say anything about when reacting nodes could change their list of supported algorithms. That leaves us with the question about what happens if a reporting node has an active OCS, and gets a new request with an OC-S-F that does not support the active algorithm.

The obvious answer is that reacting nodes shouldn't do that-- but I think there would still be legal scenarios where it could happen anyway. So even if we say that a single reacting node should not change its algorithm list while it has active OCS, we still need to handle the situation for reporting nodes.
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime



              

              
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime



            

            
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


          

          

        

        

      

      



    

    

  


--------------080607050504080904040303--


From nobody Wed Dec 17 10:40:52 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BFF1A1B8B for ; Wed, 17 Dec 2014 10:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yp4zdBz4BQOh for ; Wed, 17 Dec 2014 10:40:43 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.244.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F3881A1B75 for ; Wed, 17 Dec 2014 10:40:43 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54192 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y1JWa-0000eN-Jr; Wed, 17 Dec 2014 10:40:42 -0800
Message-ID: <5491CE28.2020205@usdonovans.com>
Date: Wed, 17 Dec 2014 12:40:40 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Campbell 
References: <0AF415BD-4AA8-4A4F-942B-29DA6C9E417B@nostrum.com> <549193B8.6000603@usdonovans.com>  <5491B2BB.30709@usdonovans.com> <3543DB65-DFC1-4ADE-8808-7B931F325F92@nostrum.com>
In-Reply-To: <3543DB65-DFC1-4ADE-8808-7B931F325F92@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=0.6
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/aACpzTwlkrK6brJXXF2Bg82NFjM
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: duration unit
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 18:40:51 -0000

I don't feel strongly one way or the other.  This was changed based on 
discussions at the interim meeting.  I believe Maria Cruz originally 
proposed it.

One other approach, if we don't want to support durations of .001 
seconds would be to put a minimum duration but allow millisecond 
granularity above that.

I'll step out of the argument and let someone else be champion for 
millisecond granularity.

Steve

On 12/17/14, 11:28 AM, Ben Campbell wrote:
>> On Dec 17, 2014, at 10:43 AM, Steve Donovan  wrote:
>>
>>
>> On 12/17/14, 10:30 AM, Ben Campbell wrote:
>>> Why would you ever set validity duration to a small number of milliseconds?
>> Why not?
> Because it's false precision. It's more likely to be harmful than useful. The precision of a value should be appropriate for it's the precision of its measurement. Inappropriate precision leads to bad decisions. [1]
>
> The validity duration means one of two things, or a combination of them: 1) I estimate that I will be overloaded for roughly X time and/or 2) I will tell you if I am still overloaded, with sufficient notice you can reasonably act on it before the expiration.
>
> (Of the two, I think 2) is the more realistic.)
>
> For 1: If we think we can estimate how long it you are likely to be overloaded down to sub-second precision, I'd like to see the magic prediction algorithm.
>
> For 2: Sub second validity durations require multiple updates a second to refresh the OLR state. That creates a _lot_ of almost certainly useless work for the reacting node.
>
>
> [1] http://en.wikipedia.org/wiki/False_precision
>
>
>>> I think asking nodes to take transit time into consideration adds considerable complexity.
>> I don't see that saying that validity duration values less then the RTT should be avoided is adding considerable complexity.
> We currently don't have a requirement to estimate RTT, other than "we assume it's not crazy big." This would add one.
>
>>>> On Dec 17, 2014, at 8:31 AM, Steve Donovan  wrote:
>>>>
>>>> Why not change the paragraph in section 4.2.3 to indicate that the transit time should be taken into consideration when setting validity duration to a small number or milliseconds?
>>>>
>>>> Steve
>>>>
>>>> On 12/16/14, 10:55 PM, Ben Campbell wrote:
>>>>> We currently define the unit for OC-Validity-Duration as milliseconds.
>>>>>
>>>>> Section 4.2.3 says (in a note) that transit time for OLRs can be safely ignored. That is likely true if the validity durations can generally be assumed to be long in comparison to transit time. It is _not_ true if validity duration can be a small number of milliseconds. That could lead to situations where the reporting node thinks the report has expired before the reacting node even sees it.
>>>>>
>>>>> Really, I don't think milliseconds are a reasonable unit here. I can't imagine any useful and safe application for sub-second validity durations, nor can I imagine it ever being useful to distinguish between X seconds and X + 0.001 seconds. We should choose a unit that lends itself to reasonable value ranges. I suggest we change it to seconds.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> /Ben.
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Wed Dec 17 10:52:02 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAFE1A700B for ; Wed, 17 Dec 2014 10:51:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id letVoEWKgyEc for ; Wed, 17 Dec 2014 10:51:50 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5E9F1A1B9B for ; Wed, 17 Dec 2014 10:51:45 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBHIpiQt093179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2014 12:51:45 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5491CCC9.3090809@usdonovans.com>
Date: Wed, 17 Dec 2014 12:51:44 -0600
X-Mao-Original-Outgoing-Id: 440535103.945728-2d2e6d6fc12cb10062dec00810c1cf62
Content-Transfer-Encoding: quoted-printable
Message-Id: <8D669BA2-05AD-496C-9B96-109ABF703A07@nostrum.com>
References:  <54912CBA.8080701@gmail.com> <549192FD.7060403@usdonovans.com>  <5491BCB3.30608@usdonovans.com> <0EEB7B88-CEEF-4A33-BD61-E4378F0D054D@nostrum.com> <5491CCC9.3090809@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/uaLVz99HQ1jzf3_8WXJZekynseU
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: Changing Algorithms
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 18:51:52 -0000

> On Dec 17, 2014, at 12:34 PM, Steve Donovan  =
wrote:
>=20
>> Where does the draft say or even imply that? It would make sense if =
we were asking for different abatement for C1 and C2, but we are not.  =
But in any case, consider the single client example above.
> SRD> Section 4.1.3, second paragraph - "A Diameter Agent SHOULD take =
on reacting node behavior for Diameter endpoints that do not support the =
DOIC solution."
>=20

I don't think that, as written, implies a separate virtual reacting node =
(I assume with potentially distinct capabilities) for each =
non-supporting client.=


From nobody Wed Dec 17 11:00:11 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2902F1A6FF0 for ; Wed, 17 Dec 2014 11:00:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DwDUha5u9SO for ; Wed, 17 Dec 2014 11:00:09 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D57DD1A6FEE for ; Wed, 17 Dec 2014 11:00:08 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBHJ07AN093842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2014 13:00:08 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5491CCC9.3090809@usdonovans.com>
Date: Wed, 17 Dec 2014 13:00:07 -0600
X-Mao-Original-Outgoing-Id: 440535606.616584-b40f608c373df2d250e9cbab624f6195
Content-Transfer-Encoding: quoted-printable
Message-Id: <4586B22E-3CDD-462E-8246-D55F25F4365C@nostrum.com>
References:  <54912CBA.8080701@gmail.com> <549192FD.7060403@usdonovans.com>  <5491BCB3.30608@usdonovans.com> <0EEB7B88-CEEF-4A33-BD61-E4378F0D054D@nostrum.com> <5491CCC9.3090809@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xQPccXwbhVA-O1cxv12CFtEMHzA
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: Changing Algorithms
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 19:00:10 -0000

> On Dec 17, 2014, at 12:34 PM, Steve Donovan  =
wrote:
>=20
>> Okay, new picture:
>>=20
>>     =20
>>=20
>>> On Dec 17, 2014, at 11:26 AM, Steve Donovan =

>>>  wrote:
>>>=20
>>> Ben,
>>>=20
>>> The value of the Origin-Host matters greatly here.  In both cases, =
what S needs to know is if there is a reacting node for traffic coming =
from C1 and if there is a reacting node for traffic coming from C2.
>>>=20
>> There is no assumption in the draft right now that we have a =
correlation between reacting nodes and clients. That might be required =
for client-targed OLRs, but we don't have those yet.
>>=20
>> Consider a different picture. In this case, C never supports DOIC. =
the reacting node role happens either at A1/A2 or at A3, depending on =
which flow you look at.
>>=20
>>         A1---
>>        /         \
>> C --             -------A3------S
>>        \         /
>>          A2---
>>=20
>> Now, assume the same flows, but substitute A1 for C1, A2, for C2, and =
A3 for A. All requests now have the same origin-host.
>>=20
>> Before you say this is unrealistic: The issue is the same for any =
situation where one client can send traffic across multiple agents to =
the same destination. It doesn't matter if there is one or a million.
>>=20
>=20
> SRD> Yes, this is nasty.  With attribution S can detect the scenario.  =
I'm not sure what it does once it selects it.  This can be addressed to =
some degree by adding a deployment recommendation that  all agents =
taking on reacting node functionality for a single endpoint  select the =
same algorithm. =20


I think some sort of attribution is the long-term solution. Another =
option might be some sort of DCA state identifier, or a combination of =
the two. (e.g. multiple "virtual" reacting node at the same physical =
node.) The details will be non-trivial to figure out.

But to close the loop, I think the _short_ term solution is to say that, =
while a reporting node should not _initiate_ a change in algorithms =
during an overload condition, it must still handle the situation where =
the reacting node forces a change. We could go further to say that =
reacting node also should not initiate such a change, but we would have =
to recognize that there are scenarios where that guidance cannot be =
enforced, and the reporting node still has to handle them.

We might need to think about what it means from an OCS perspective for a =
reporting node to send OLRs with different algorithms (or potentially =
other capability parameters) for the "same" overload event.=20


From nobody Wed Dec 17 11:03:59 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F5E1A7016 for ; Wed, 17 Dec 2014 11:03:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.39
X-Spam-Level: 
X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TOOL=2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRy1QhW6F5bv for ; Wed, 17 Dec 2014 11:03:52 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B50C1A1BC4 for ; Wed, 17 Dec 2014 11:03:52 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBHJ3p66094209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2014 13:03:51 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5491CE28.2020205@usdonovans.com>
Date: Wed, 17 Dec 2014 13:03:50 -0600
X-Mao-Original-Outgoing-Id: 440535830.889892-3fbaa4a7bbdf9f309d1bbc9547bc667d
Content-Transfer-Encoding: quoted-printable
Message-Id: <0E11AEDD-6E90-4D61-8759-557B8596BAFB@nostrum.com>
References: <0AF415BD-4AA8-4A4F-942B-29DA6C9E417B@nostrum.com> <549193B8.6000603@usdonovans.com>  <5491B2BB.30709@usdonovans.com> <3543DB65-DFC1-4ADE-8808-7B931F325F92@nostrum.com> <5491CE28.2020205@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/TFAXWPcLkNhkSAnGOkurUzmizEg
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: duration unit
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 19:03:57 -0000

> On Dec 17, 2014, at 12:40 PM, Steve Donovan  =
wrote:
>=20
> I don't feel strongly one way or the other.  This was changed based on =
discussions at the interim meeting.  I believe Maria Cruz originally =
proposed it.
>=20
> One other approach, if we don't want to support durations of .001 =
seconds would be to put a minimum duration but allow millisecond =
granularity above that.

That brings up the question about whether there is any point to =
distinguish a duration of X from a duration of X+.001. My gut tells me =
that's still a false precision problem.

(Honestly, I think 1 second precision is pushing it, but the next =
natural resolution is 1 minute, which seems too blunt. We could do =
something like units of 10s, but I suspect that would be =
counter-intuitive enough to cause implementation errors.)

>=20
> I'll step out of the argument and let someone else be champion for =
millisecond granularity.

Any other takers? Are there real use cases for sub-second precision?

>=20
> Steve
>=20
> On 12/17/14, 11:28 AM, Ben Campbell wrote:
>>> On Dec 17, 2014, at 10:43 AM, Steve Donovan =
 wrote:
>>>=20
>>>=20
>>> On 12/17/14, 10:30 AM, Ben Campbell wrote:
>>>> Why would you ever set validity duration to a small number of =
milliseconds?
>>> Why not?
>> Because it's false precision. It's more likely to be harmful than =
useful. The precision of a value should be appropriate for it's the =
precision of its measurement. Inappropriate precision leads to bad =
decisions. [1]
>>=20
>> The validity duration means one of two things, or a combination of =
them: 1) I estimate that I will be overloaded for roughly X time and/or =
2) I will tell you if I am still overloaded, with sufficient notice you =
can reasonably act on it before the expiration.
>>=20
>> (Of the two, I think 2) is the more realistic.)
>>=20
>> For 1: If we think we can estimate how long it you are likely to be =
overloaded down to sub-second precision, I'd like to see the magic =
prediction algorithm.
>>=20
>> For 2: Sub second validity durations require multiple updates a =
second to refresh the OLR state. That creates a _lot_ of almost =
certainly useless work for the reacting node.
>>=20
>>=20
>> [1] http://en.wikipedia.org/wiki/False_precision
>>=20
>>=20
>>>> I think asking nodes to take transit time into consideration adds =
considerable complexity.
>>> I don't see that saying that validity duration values less then the =
RTT should be avoided is adding considerable complexity.
>> We currently don't have a requirement to estimate RTT, other than "we =
assume it's not crazy big." This would add one.
>>=20
>>>>> On Dec 17, 2014, at 8:31 AM, Steve Donovan =
 wrote:
>>>>>=20
>>>>> Why not change the paragraph in section 4.2.3 to indicate that the =
transit time should be taken into consideration when setting validity =
duration to a small number or milliseconds?
>>>>>=20
>>>>> Steve
>>>>>=20
>>>>> On 12/16/14, 10:55 PM, Ben Campbell wrote:
>>>>>> We currently define the unit for OC-Validity-Duration as =
milliseconds.
>>>>>>=20
>>>>>> Section 4.2.3 says (in a note) that transit time for OLRs can be =
safely ignored. That is likely true if the validity durations can =
generally be assumed to be long in comparison to transit time. It is =
_not_ true if validity duration can be a small number of milliseconds. =
That could lead to situations where the reporting node thinks the report =
has expired before the reacting node even sees it.
>>>>>>=20
>>>>>> Really, I don't think milliseconds are a reasonable unit here. I =
can't imagine any useful and safe application for sub-second validity =
durations, nor can I imagine it ever being useful to distinguish between =
X seconds and X + 0.001 seconds. We should choose a unit that lends =
itself to reasonable value ranges. I suggest we change it to seconds.
>>>>>>=20
>>>>>> Thanks!
>>>>>>=20
>>>>>> /Ben.
>>>>>> _______________________________________________
>>>>>> DiME mailing list
>>>>>> DiME@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>=20


From nobody Wed Dec 17 13:35:39 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58951A87ED for ; Wed, 17 Dec 2014 13:35:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyrfxdaBICtG for ; Wed, 17 Dec 2014 13:35:36 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.244.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9AF01A87A6 for ; Wed, 17 Dec 2014 13:35:36 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54949 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y1MFn-000CJi-Mj; Wed, 17 Dec 2014 13:35:32 -0800
Message-ID: <5491F723.6080203@usdonovans.com>
Date: Wed, 17 Dec 2014 15:35:31 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Ben Campbell 
References:  <54912CBA.8080701@gmail.com> <549192FD.7060403@usdonovans.com>  <5491BCB3.30608@usdonovans.com> <0EEB7B88-CEEF-4A33-BD61-E4378F0D054D@nostrum.com> <5491CCC9.3090809@usdonovans.com> <4586B22E-3CDD-462E-8246-D55F25F4365C@nostrum.com>
In-Reply-To: <4586B22E-3CDD-462E-8246-D55F25F4365C@nostrum.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=0.6
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/41_yiCcEBD7uOb-MZ-8K7bw9YQE
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: Changing Algorithms
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 21:35:37 -0000

On 12/17/14 1:00 PM, Ben Campbell wrote:
>> On Dec 17, 2014, at 12:34 PM, Steve Donovan  wrote:
>>
>>> Okay, new picture:
>>>
>>>       
>>>
>>>> On Dec 17, 2014, at 11:26 AM, Steve Donovan 
>>>>   wrote:
>>>>
>>>> Ben,
>>>>
>>>> The value of the Origin-Host matters greatly here.  In both cases, what S needs to know is if there is a reacting node for traffic coming from C1 and if there is a reacting node for traffic coming from C2.
>>>>
>>> There is no assumption in the draft right now that we have a correlation between reacting nodes and clients. That might be required for client-targed OLRs, but we don't have those yet.
>>>
>>> Consider a different picture. In this case, C never supports DOIC. the reacting node role happens either at A1/A2 or at A3, depending on which flow you look at.
>>>
>>>          A1---
>>>         /         \
>>> C --             -------A3------S
>>>         \         /
>>>           A2---
>>>
>>> Now, assume the same flows, but substitute A1 for C1, A2, for C2, and A3 for A. All requests now have the same origin-host.
>>>
>>> Before you say this is unrealistic: The issue is the same for any situation where one client can send traffic across multiple agents to the same destination. It doesn't matter if there is one or a million.
>>>
>> SRD> Yes, this is nasty.  With attribution S can detect the scenario.  I'm not sure what it does once it selects it.  This can be addressed to some degree by adding a deployment recommendation that  all agents taking on reacting node functionality for a single endpoint  select the same algorithm.
>
> I think some sort of attribution is the long-term solution. Another option might be some sort of DCA state identifier, or a combination of the two. (e.g. multiple "virtual" reacting node at the same physical node.) The details will be non-trivial to figure out.
>
> But to close the loop, I think the _short_ term solution is to say that, while a reporting node should not _initiate_ a change in algorithms during an overload condition, it must still handle the situation where the reacting node forces a change. We could go further to say that reacting node also should not initiate such a change, but we would have to recognize that there are scenarios where that guidance cannot be enforced, and the reporting node still has to handle them.
>
> We might need to think about what it means from an OCS perspective for a reporting node to send OLRs with different algorithms (or potentially other capability parameters) for the "same" overload event.
SRD> I think it is a better solution to stay with what we have now.  The 
reporting node MUST NOT change the algorithm during an active overload 
condition.  If a reacting node advertises support for it, the reacting 
node is saying it will support that algorithm for the duration of any 
overload condition that happens prior to the reacting node changing the 
advertised algorithm.  The change in advertised algorithm will take 
effect after the overload condition goes away.

SRD> I don't think we need to update the OCS in this document to handle 
multiple algorithms.  This can be done in the extension drafts.  We 
might want to make it clear, as it appears it isn't already, that a 
reacting node might need to support multiple algorithms at the same time.
>
>


From nobody Wed Dec 17 13:54:21 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDA21A70FD for ; Wed, 17 Dec 2014 13:54:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3TVOSMkQMJp for ; Wed, 17 Dec 2014 13:54:17 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D9D1A7021 for ; Wed, 17 Dec 2014 13:54:17 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBHLsEEe008652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2014 15:54:16 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5491F723.6080203@usdonovans.com>
Date: Wed, 17 Dec 2014 15:54:14 -0600
X-Mao-Original-Outgoing-Id: 440546053.89789-c6f5263ed257bf14ecb13ddf9c4727a1
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <54912CBA.8080701@gmail.com> <549192FD.7060403@usdonovans.com>  <5491BCB3.30608@usdonovans.com> <0EEB7B88-CEEF-4A33-BD61-E4378F0D054D@nostrum.com> <5491CCC9.3090809@usdonovans.com> <4586B22E-3CDD-462E-8246-D55F25F4365C@nostrum.com> <5491F723.6080203@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/DXbp7bd_yLJuIjyRhlLaPrncswM
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: Changing Algorithms
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 21:54:20 -0000

> On Dec 17, 2014, at 3:35 PM, Steve Donovan  =
wrote:
>=20
>=20
> On 12/17/14 1:00 PM, Ben Campbell wrote:
>>> On Dec 17, 2014, at 12:34 PM, Steve Donovan =
 wrote:
>>>=20
>>>> Okay, new picture:
>>>>=20
>>>>     =20
>>>>> On Dec 17, 2014, at 11:26 AM, Steve Donovan =

>>>>>  wrote:
>>>>>=20
>>>>> Ben,
>>>>>=20
>>>>> The value of the Origin-Host matters greatly here.  In both cases, =
what S needs to know is if there is a reacting node for traffic coming =
from C1 and if there is a reacting node for traffic coming from C2.
>>>>>=20
>>>> There is no assumption in the draft right now that we have a =
correlation between reacting nodes and clients. That might be required =
for client-targed OLRs, but we don't have those yet.
>>>>=20
>>>> Consider a different picture. In this case, C never supports DOIC. =
the reacting node role happens either at A1/A2 or at A3, depending on =
which flow you look at.
>>>>=20
>>>>         A1---
>>>>        /         \
>>>> C --             -------A3------S
>>>>        \         /
>>>>          A2---
>>>>=20
>>>> Now, assume the same flows, but substitute A1 for C1, A2, for C2, =
and A3 for A. All requests now have the same origin-host.
>>>>=20
>>>> Before you say this is unrealistic: The issue is the same for any =
situation where one client can send traffic across multiple agents to =
the same destination. It doesn't matter if there is one or a million.
>>>>=20
>>> SRD> Yes, this is nasty.  With attribution S can detect the =
scenario.  I'm not sure what it does once it selects it.  This can be =
addressed to some degree by adding a deployment recommendation that  all =
agents taking on reacting node functionality for a single endpoint  =
select the same algorithm.
>>=20
>> I think some sort of attribution is the long-term solution. Another =
option might be some sort of DCA state identifier, or a combination of =
the two. (e.g. multiple "virtual" reacting node at the same physical =
node.) The details will be non-trivial to figure out.
>>=20
>> But to close the loop, I think the _short_ term solution is to say =
that, while a reporting node should not _initiate_ a change in =
algorithms during an overload condition, it must still handle the =
situation where the reacting node forces a change. We could go further =
to say that reacting node also should not initiate such a change, but we =
would have to recognize that there are scenarios where that guidance =
cannot be enforced, and the reporting node still has to handle them.
>>=20
>> We might need to think about what it means from an OCS perspective =
for a reporting node to send OLRs with different algorithms (or =
potentially other capability parameters) for the "same" overload event.
> SRD> I think it is a better solution to stay with what we have now.  =
The reporting node MUST NOT change the algorithm during an active =
overload condition.  If a reacting node advertises support for it, the =
reacting node is saying it will support that algorithm for the duration =
of any overload condition that happens prior to the reacting node =
changing the advertised algorithm.  The change in advertised algorithm =
will take effect after the overload condition goes away.
>=20

I disagree. I don't think we want to allow the reporting node to ever =
indicate an algorithm that was not advertised in the request. That =
violates normative language earlier in the section that says the =
selected algorithm MUST be one of the ones advertised in the request. It =
can also cause problems for reacting nodes, where they get OLRs for an =
algorithm they don't understand.=20

I think that's considerably more important that restricting the =
reporting node from changing algorithms (Which, btw, does no harm with =
the only algorithms that we are seriously contemplating.We speculate =
that it might cause harm for some future algorithm.)

Remember, this is not just about a single reacting node changing it's =
capabilities, it's also about multiple reacting nodes with different =
capabilities. We can't disallow one without disallowing the other.


> SRD> I don't think we need to update the OCS in this document to =
handle multiple algorithms.  This can be done in the extension drafts.  =
We might want to make it clear, as it appears it isn't already, that a =
reacting node might need to support multiple algorithms at the same =
time.

Do you mean reacting or reporting node in the last sentence? Assuming =
you mean it as written, the problem is not that a reacting node may need =
to support multiple algorithms at the same time. It's that it may get =
OLRs that it cannot act upon because it doesn't support the algorithm.

If, otoh, you meant reporting node, I don't understand how a reporting =
node can have multiple algorithms for the same overload event, without =
reflecting that possibility in the OCS.



>>=20
>>=20
>=20


From nobody Wed Dec 17 14:23:52 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5D61A874B for ; Wed, 17 Dec 2014 14:23:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEgjqJHfnWFC for ; Wed, 17 Dec 2014 14:23:49 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.244.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5553A1A876F for ; Wed, 17 Dec 2014 14:23:49 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:55380 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y1N0U-0000J8-3u; Wed, 17 Dec 2014 14:23:47 -0800
Message-ID: <54920272.80508@usdonovans.com>
Date: Wed, 17 Dec 2014 16:23:46 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Ben Campbell 
References:  <54912CBA.8080701@gmail.com> <549192FD.7060403@usdonovans.com>  <5491BCB3.30608@usdonovans.com> <0EEB7B88-CEEF-4A33-BD61-E4378F0D054D@nostrum.com> <5491CCC9.3090809@usdonovans.com> <4586B22E-3CDD-462E-8246-D55F25F4365C@nostrum.com> <5491F723.6080203@usdonovans.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=0.6
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-LIUGkQGgTeIEovkfPRAswiUXUM
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: Changing Algorithms
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 22:23:51 -0000

On 12/17/14 3:54 PM, Ben Campbell wrote:
>> On Dec 17, 2014, at 3:35 PM, Steve Donovan  wrote:
>>
>>
>> On 12/17/14 1:00 PM, Ben Campbell wrote:
>>>> On Dec 17, 2014, at 12:34 PM, Steve Donovan  wrote:
>>>>
>>>>> Okay, new picture:
>>>>>
>>>>>       
>>>>>> On Dec 17, 2014, at 11:26 AM, Steve Donovan 
>>>>>>   wrote:
>>>>>>
>>>>>> Ben,
>>>>>>
>>>>>> The value of the Origin-Host matters greatly here.  In both cases, what S needs to know is if there is a reacting node for traffic coming from C1 and if there is a reacting node for traffic coming from C2.
>>>>>>
>>>>> There is no assumption in the draft right now that we have a correlation between reacting nodes and clients. That might be required for client-targed OLRs, but we don't have those yet.
>>>>>
>>>>> Consider a different picture. In this case, C never supports DOIC. the reacting node role happens either at A1/A2 or at A3, depending on which flow you look at.
>>>>>
>>>>>          A1---
>>>>>         /         \
>>>>> C --             -------A3------S
>>>>>         \         /
>>>>>           A2---
>>>>>
>>>>> Now, assume the same flows, but substitute A1 for C1, A2, for C2, and A3 for A. All requests now have the same origin-host.
>>>>>
>>>>> Before you say this is unrealistic: The issue is the same for any situation where one client can send traffic across multiple agents to the same destination. It doesn't matter if there is one or a million.
>>>>>
>>>> SRD> Yes, this is nasty.  With attribution S can detect the scenario.  I'm not sure what it does once it selects it.  This can be addressed to some degree by adding a deployment recommendation that  all agents taking on reacting node functionality for a single endpoint  select the same algorithm.
>>> I think some sort of attribution is the long-term solution. Another option might be some sort of DCA state identifier, or a combination of the two. (e.g. multiple "virtual" reacting node at the same physical node.) The details will be non-trivial to figure out.
>>>
>>> But to close the loop, I think the _short_ term solution is to say that, while a reporting node should not _initiate_ a change in algorithms during an overload condition, it must still handle the situation where the reacting node forces a change. We could go further to say that reacting node also should not initiate such a change, but we would have to recognize that there are scenarios where that guidance cannot be enforced, and the reporting node still has to handle them.
>>>
>>> We might need to think about what it means from an OCS perspective for a reporting node to send OLRs with different algorithms (or potentially other capability parameters) for the "same" overload event.
>> SRD> I think it is a better solution to stay with what we have now.  The reporting node MUST NOT change the algorithm during an active overload condition.  If a reacting node advertises support for it, the reacting node is saying it will support that algorithm for the duration of any overload condition that happens prior to the reacting node changing the advertised algorithm.  The change in advertised algorithm will take effect after the overload condition goes away.
>>
> I disagree. I don't think we want to allow the reporting node to ever indicate an algorithm that was not advertised in the request. That violates normative language earlier in the section that says the selected algorithm MUST be one of the ones advertised in the request. It can also cause problems for reacting nodes, where they get OLRs for an algorithm they don't understand.
SRD> They clearly do understand the algorithm.  They advertised it 
before the overload report started.  We can change the normative 
language to cover this exception.  I think the principle of minimizing 
work on an overloaded reporting node is the more important principle 
here.  If the reacting node changes the advertised set of algorithms 
during an active overload condition then the overloaded reporting node 
will be required to send end-of-overload OLRs for the previous algorithm 
and then send start-of-overload OLRs for the new algorithm.  This seems 
complex at a time the overloaded node should be focusing on getting out 
of the overload condition.
>
> I think that's considerably more important that restricting the reporting node from changing algorithms (Which, btw, does no harm with the only algorithms that we are seriously contemplating.We speculate that it might cause harm for some future algorithm.)
SRD> We already have the restriction on the reporting node.
>
> Remember, this is not just about a single reacting node changing it's capabilities, it's also about multiple reacting nodes with different capabilities. We can't disallow one without disallowing the other.
SRD> Multiple reacting nodes with different capabilities is all the more 
reason to hold things constant during an overload condition.  I'm not 
proposing disallowing reacting nodes from changing the set of 
capabilities, I'm proposing that these changes don't take effect while 
there is an active overload condition.
>
>
>> SRD> I don't think we need to update the OCS in this document to handle multiple algorithms.  This can be done in the extension drafts.  We might want to make it clear, as it appears it isn't already, that a reacting node might need to support multiple algorithms at the same time.
> Do you mean reacting or reporting node in the last sentence? Assuming you mean it as written, the problem is not that a reacting node may need to support multiple algorithms at the same time. It's that it may get OLRs that it cannot act upon because it doesn't support the algorithm.
SRD> I meant reporting nodes.
>
> If, otoh, you meant reporting node, I don't understand how a reporting node can have multiple algorithms for the same overload event, without reflecting that possibility in the OCS.
SRD> Yes, it will need to be reflected in the OCS.  We don't have 
multiple algorithms now so it isn't needed now.  I'm saying we might 
want to say it might me needed in the future.
>
>
>
>>>
>


From nobody Wed Dec 17 14:33:18 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6CE1A875E; Wed, 17 Dec 2014 14:33:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH8Hzn7PzhcF; Wed, 17 Dec 2014 14:33:12 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3881A6FDB; Wed, 17 Dec 2014 14:33:12 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141217223312.6301.31887.idtracker@ietfa.amsl.com>
Date: Wed, 17 Dec 2014 14:33:12 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/L3KdS88TyhZxTBZTXFWqM0B3kJg
Cc: dime@ietf.org
Subject: [Dime] I-D Action: draft-ietf-dime-doic-rate-control-00.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 22:33:14 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF.

        Title           : Diameter Overload Rate Control
        Authors         : Steve Donovan
                          Eric Noel
	Filename        : draft-ietf-dime-doic-rate-control-00.txt
	Pages           : 18
	Date            : 2014-12-17

Abstract:
   This specification documents an extension to the Diameter Overload
   Indication Conveyance (DOIC) base solution.  This extension adds a
   new overload control abatement algorithm.  This abatement algorithm
   allows for a DOIC reporting node to specify a maximum rate at which a
   DOIC reacting node sends Diameter requests sent to the DOIC reporting
   node.

Requirements

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dime-doic-rate-control-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Dec 17 14:33:38 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1E01A8779; Wed, 17 Dec 2014 14:33:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHa_4DMVwNZO; Wed, 17 Dec 2014 14:33:29 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE131A8783; Wed, 17 Dec 2014 14:33:28 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141217223328.3890.2769.idtracker@ietfa.amsl.com>
Date: Wed, 17 Dec 2014 14:33:28 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/cmg6BfSXf8nz8Owp2-szVLrAXqQ
Cc: dime@ietf.org
Subject: [Dime] I-D Action: draft-ietf-dime-agent-overload-00.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 22:33:31 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF.

        Title           : Diameter Agent Overload
        Author          : Steve Donovan
	Filename        : draft-ietf-dime-agent-overload-00.txt
	Pages           : 18
	Date            : 2014-12-17

Abstract:
   This specification documents an extension to the Diameter Overload
   Control (DOC) base solution.  The extension addresses the handling of
   occurrances of overload of a Diameter agent.

Requirements

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dime-agent-overload-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Dec 17 14:39:02 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC101A0121 for ; Wed, 17 Dec 2014 14:39:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CPmb-K2DJXl for ; Wed, 17 Dec 2014 14:38:57 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA4F51A008D for ; Wed, 17 Dec 2014 14:38:57 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBHMcuFW012314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2014 16:38:57 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <54920272.80508@usdonovans.com>
Date: Wed, 17 Dec 2014 16:38:56 -0600
X-Mao-Original-Outgoing-Id: 440548736.441289-fba32af7028bdf11db4fa1ff312e1ae8
Content-Transfer-Encoding: quoted-printable
Message-Id: <52901958-73B6-49FE-8DA4-A8D2F8276DD0@nostrum.com>
References:  <54912CBA.8080701@gmail.com> <549192FD.7060403@usdonovans.com>  <5491BCB3.30608@usdonovans.com> <0EEB7B88-CEEF-4A33-BD61-E4378F0D054D@nostrum.com> <5491CCC9.3090809@usdonovans.com> <4586B22E-3CDD-462E-8246-D55F25F4365C@nostrum.com> <5491F723.6080203@usdonovans.com>  <54920272.80508@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/N75rvmeB7F-ebPT-bTYElqwRO7g
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: Changing Algorithms
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 22:39:00 -0000

> On Dec 17, 2014, at 4:23 PM, Steve Donovan  =
wrote:
>=20
>=20
> On 12/17/14 3:54 PM, Ben Campbell wrote:
>>> On Dec 17, 2014, at 3:35 PM, Steve Donovan =
 wrote:
>>>=20
>>>=20
>>> On 12/17/14 1:00 PM, Ben Campbell wrote:
>>>>> On Dec 17, 2014, at 12:34 PM, Steve Donovan =
 wrote:
>>>>>=20
>>>>>> Okay, new picture:
>>>>>>=20
>>>>>>     =20
>>>>>>> On Dec 17, 2014, at 11:26 AM, Steve Donovan =

>>>>>>>  wrote:
>>>>>>>=20
>>>>>>> Ben,
>>>>>>>=20
>>>>>>> The value of the Origin-Host matters greatly here.  In both =
cases, what S needs to know is if there is a reacting node for traffic =
coming from C1 and if there is a reacting node for traffic coming from =
C2.
>>>>>>>=20
>>>>>> There is no assumption in the draft right now that we have a =
correlation between reacting nodes and clients. That might be required =
for client-targed OLRs, but we don't have those yet.
>>>>>>=20
>>>>>> Consider a different picture. In this case, C never supports =
DOIC. the reacting node role happens either at A1/A2 or at A3, depending =
on which flow you look at.
>>>>>>=20
>>>>>>         A1---
>>>>>>        /         \
>>>>>> C --             -------A3------S
>>>>>>        \         /
>>>>>>          A2---
>>>>>>=20
>>>>>> Now, assume the same flows, but substitute A1 for C1, A2, for C2, =
and A3 for A. All requests now have the same origin-host.
>>>>>>=20
>>>>>> Before you say this is unrealistic: The issue is the same for any =
situation where one client can send traffic across multiple agents to =
the same destination. It doesn't matter if there is one or a million.
>>>>>>=20
>>>>> SRD> Yes, this is nasty.  With attribution S can detect the =
scenario.  I'm not sure what it does once it selects it.  This can be =
addressed to some degree by adding a deployment recommendation that  all =
agents taking on reacting node functionality for a single endpoint  =
select the same algorithm.
>>>> I think some sort of attribution is the long-term solution. Another =
option might be some sort of DCA state identifier, or a combination of =
the two. (e.g. multiple "virtual" reacting node at the same physical =
node.) The details will be non-trivial to figure out.
>>>>=20
>>>> But to close the loop, I think the _short_ term solution is to say =
that, while a reporting node should not _initiate_ a change in =
algorithms during an overload condition, it must still handle the =
situation where the reacting node forces a change. We could go further =
to say that reacting node also should not initiate such a change, but we =
would have to recognize that there are scenarios where that guidance =
cannot be enforced, and the reporting node still has to handle them.
>>>>=20
>>>> We might need to think about what it means from an OCS perspective =
for a reporting node to send OLRs with different algorithms (or =
potentially other capability parameters) for the "same" overload event.
>>> SRD> I think it is a better solution to stay with what we have now.  =
The reporting node MUST NOT change the algorithm during an active =
overload condition.  If a reacting node advertises support for it, the =
reacting node is saying it will support that algorithm for the duration =
of any overload condition that happens prior to the reacting node =
changing the advertised algorithm.  The change in advertised algorithm =
will take effect after the overload condition goes away.
>>>=20
>> I disagree. I don't think we want to allow the reporting node to ever =
indicate an algorithm that was not advertised in the request. That =
violates normative language earlier in the section that says the =
selected algorithm MUST be one of the ones advertised in the request. It =
can also cause problems for reacting nodes, where they get OLRs for an =
algorithm they don't understand.
> SRD> They clearly do understand the algorithm.  They advertised it =
before the overload report started.  We can change the normative =
language to cover this exception.

In my first scenario, this is not true. C2 (or A2)  _never_ understood =
the rate algorithm, and never advertised support for it.

The whole point of this exercise was to show that the reporting node =
cannot, in the general case, distinguish between multiple reacting nodes =
with different capabilities, and a single reacting node that changes =
capabilities.

By "general case", I mean no assumption that the reacting nodes are =
peers with the reporting nodes, and no assumption that you can correlate =
origin-host values (in requests) to reacting-nodes.=20


>  I think the principle of minimizing work on an overloaded reporting =
node is the more important principle here.  If the reacting node changes =
the advertised set of algorithms during an active overload condition =
then the overloaded reporting node will be required to send =
end-of-overload OLRs for the previous algorithm and then send =
start-of-overload OLRs for the new algorithm.  This seems complex at a =
time the overloaded node should be focusing on getting out of the =
overload condition.

Sending an OLR that the reacting node does not understand will not help =
you get out of overload.

I don't see how this is any more complex that if you simply have =
multiple reacting nodes with different capabilities--and I don't see how =
to avoid supporting that case.

>>=20
>> I think that's considerably more important that restricting the =
reporting node from changing algorithms (Which, btw, does no harm with =
the only algorithms that we are seriously contemplating.We speculate =
that it might cause harm for some future algorithm.)
> SRD> We already have the restriction on the reporting node.

We already have both restrictions, and they contradict. I believe the =
_existing_ restriction to not select an algorithm that is not advertised =
in the request is more important than the _existing_ restriction to not =
change algorithms during an overload condition.


>>=20
>> Remember, this is not just about a single reacting node changing it's =
capabilities, it's also about multiple reacting nodes with different =
capabilities. We can't disallow one without disallowing the other.
> SRD> Multiple reacting nodes with different capabilities is all the =
more reason to hold things constant during an overload condition.

I don't follow that. You seem to be pushing towards using the same =
algorithm for all reacting nodes once an overload condition starts. Is =
that your intent?  (Given the possibility that some future reacting node =
will only support "loss", that "same algorithm" would pretty much always =
need to be loss.)

>  I'm not proposing disallowing reacting nodes from changing the set of =
capabilities, I'm proposing that these changes don't take effect while =
there is an active overload condition.

The problem exists even if no reacting node ever changes its =
capabilities.

>>=20
>>=20
>>> SRD> I don't think we need to update the OCS in this document to =
handle multiple algorithms.  This can be done in the extension drafts.  =
We might want to make it clear, as it appears it isn't already, that a =
reacting node might need to support multiple algorithms at the same =
time.
>> Do you mean reacting or reporting node in the last sentence? Assuming =
you mean it as written, the problem is not that a reacting node may need =
to support multiple algorithms at the same time. It's that it may get =
OLRs that it cannot act upon because it doesn't support the algorithm.
> SRD> I meant reporting nodes.
>>=20
>> If, otoh, you meant reporting node, I don't understand how a =
reporting node can have multiple algorithms for the same overload event, =
without reflecting that possibility in the OCS.
> SRD> Yes, it will need to be reflected in the OCS.  We don't have =
multiple algorithms now so it isn't needed now.  I'm saying we might =
want to say it might me needed in the future.

I'd rather not make each new algorithm redefine the basic structure of =
OCS.

But, if you recall, my point was to say we need to _think_ about how =
this impacts OCS, not that we necessarily need to change anything. Are =
you opposed to thinking about it? (And no, I don't think this short =
exchange quite counts as that.)

>>=20
>>=20
>>=20
>>>>=20
>>=20
>=20


From nobody Wed Dec 17 15:01:18 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC681A0024 for ; Wed, 17 Dec 2014 15:01:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfmbEV-hRg3r for ; Wed, 17 Dec 2014 15:01:15 -0800 (PST)
Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7DC51A000A for ; Wed, 17 Dec 2014 15:01:14 -0800 (PST)
Received: by mail-la0-f50.google.com with SMTP id pn19so33618lab.37 for ; Wed, 17 Dec 2014 15:01:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=9KItW6IVCK+vgDEUvt3ySQZwn/M5Ev6KjegkGB+bwzE=; b=wqb1yyL1p987c3AuBX73BGP/7wJxeODEK6+yxtjOmHFyTqu2Eln+FgzdexwzpINhHw SNyV32uSPaHi6IsU+SPiQS5UfkZf6vDZ1RNj7ysFbGjb0a0+uhk+8Ko5xQP2ATqiJChG 3LkdYmCZ/7Uwm2F2ChOQHR5XR/p9B8126nnmiDPSv/wrwAjSAYek+D7PwMrKCCjXL5SN PFRyrEs4Jvy8aa1XotMNW4DkkvU+0xCsQByg4OsBoja7HC2K/aAPkRA8M8hXXF7Sk8yE lGiDv1xlGTdVPIBPp8K5C/JdZkGqLMgK2qnGHpI2j6IJPaLyOKxEySr5NqjC4isI6IZk xABA==
X-Received: by 10.152.27.228 with SMTP id w4mr32096262lag.75.1418857273439; Wed, 17 Dec 2014 15:01:13 -0800 (PST)
Received: from [10.17.0.23] ([83.150.126.201]) by mx.google.com with ESMTPSA id nv1sm1269862lbb.38.2014.12.17.15.01.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Dec 2014 15:01:12 -0800 (PST)
Message-ID: <54920B37.4060201@gmail.com>
Date: Thu, 18 Dec 2014 01:01:11 +0200
From: Jouni Korhonen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Campbell , Steve Donovan 
References: <0AF415BD-4AA8-4A4F-942B-29DA6C9E417B@nostrum.com> <549193B8.6000603@usdonovans.com>  <5491B2BB.30709@usdonovans.com> <3543DB65-DFC1-4ADE-8808-7B931F325F92@nostrum.com> <5491CE28.2020205@usdonovans.com> <0E11AEDD-6E90-4D61-8759-557B8596BAFB@nostrum.com>
In-Reply-To: <0E11AEDD-6E90-4D61-8759-557B8596BAFB@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/h23U1i22dyQ4xdyZXl80kC40TDU
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: duration unit
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 23:01:16 -0000

[snip]

>> I'll step out of the argument and let someone else be champion for millisecond granularity.
>
> Any other takers? Are there real use cases for sub-second precision?

I do not really care. We changed that from seconds to milliseconds for 
some reason.. but no not see a reason to change it back either.

- Jouni

>
>>
>> Steve
>>


From nobody Wed Dec 17 15:08:09 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC7F1A0058 for ; Wed, 17 Dec 2014 15:08:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbNunZC2yMvm for ; Wed, 17 Dec 2014 15:08:01 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16BEF1A0030 for ; Wed, 17 Dec 2014 15:07:44 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBHN7dtT014694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2014 17:07:39 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <54920B37.4060201@gmail.com>
Date: Wed, 17 Dec 2014 17:07:38 -0600
X-Mao-Original-Outgoing-Id: 440550458.489466-9e9fab1a257d7cb421242ba50ed73d2a
Content-Transfer-Encoding: quoted-printable
Message-Id: <2BE199F8-262D-40AB-A567-A857E94B3A6A@nostrum.com>
References: <0AF415BD-4AA8-4A4F-942B-29DA6C9E417B@nostrum.com> <549193B8.6000603@usdonovans.com>  <5491B2BB.30709@usdonovans.com> <3543DB65-DFC1-4ADE-8808-7B931F325F92@nostrum.com> <5491CE28.2020205@usdonovans.com> <0E11AEDD-6E90-4D61-8759-557B8596BAFB@nostrum.com> <54920B37.4060201@gmail.com>
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/3OduquFoJxUWUw9CDc8RnGZRT10
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: duration unit
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Dec 2014 23:08:07 -0000

> On Dec 17, 2014, at 5:01 PM, Jouni Korhonen  =
wrote:
>=20
> [snip]
>=20
>>> I'll step out of the argument and let someone else be champion for =
millisecond granularity.
>>=20
>> Any other takers? Are there real use cases for sub-second precision?
>=20
> I do not really care. We changed that from seconds to milliseconds for =
some reason.. but no not see a reason to change it back either.

I'd argue that we should make it the "right thing", regardless of =
whether we changed it before. (Although remembering why might go far to =
answering my last question below.)

I've describe why I think it is false precision, and can become harmful. =
To rephrase it, choosing too small of durations will cause harm by =
forcing rapid OLR updates (as in many per second.) These updates cause =
work for both reporting nodes and reacting nodes.=20

We could offer guidance of how to avoid that harm. Or we could choose a =
resolution that makes it harder to cause such harm in the first place. I =
think good protocol design favors the later.

Do you disagree with the potential for harm? Or do you see some use case =
for sub-second precision that I've missed?



From nobody Thu Dec 18 01:09:54 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFBA1A6F68 for ; Thu, 18 Dec 2014 01:09:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ5Ljyok-l5D for ; Thu, 18 Dec 2014 01:09:47 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D27A1A6F64 for ; Thu, 18 Dec 2014 01:09:46 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBI99i5Z023866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Dec 2014 09:09:44 GMT
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBI99hbY022993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Dec 2014 10:09:43 +0100
Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 18 Dec 2014 10:09:43 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 10:09:42 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , ext Ben Campbell 
Thread-Topic: [Dime] Ulrich's suggested change #16
Thread-Index: AQHQE7lXyc+G3J0M1EW8kbPFxFEQNZyHfq1QgANENfD///h3AIAAAngAgAZo/cCAASFYAIAC0YbQ
Date: Thu, 18 Dec 2014 09:09:42 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815235BEF@DEMUMBX014.nsn-intra.net>
References: <548701E1.3060502@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235234@DEMUMBX014.nsn-intra.net> <54884556.90108@usdonovans.com> <9B6C0FB1-B3D5-4050-B79D-E429A440CE79@nostrum.com> <5489F246.5040801@usdonovans.com> <8D4FC2F7-30F8-41AF-9F19-209BB48FCB9D@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668152359A7@DEMUMBX014.nsn-intra.net> <549047A0.4060503@usdonovans.com>
In-Reply-To: <549047A0.4060503@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.119]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 8619
X-purgate-ID: 151667::1418893784-0000677A-CC461740/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/HpfgJp0_yGjsJm_RV4V-JkZUQd8
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #16
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Dec 2014 09:09:53 -0000

Steve,

I'm still not convinced.

Another proposal:

If diversion abatement treatment is possible (i.e. a different path for the=
 request can be selected where the overloaded node is not part of the diffe=
rent path), then the reacting node SHOULD apply diversion abatement treatme=
nt to the request. Otherwise the reacting node SHOULD apply throttling abat=
ement treatment to the request.=20

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
Sent: Tuesday, December 16, 2014 3:54 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: dime@ietf.org
Subject: Re: [Dime] Ulrich's suggested change #16

Ulrich,

I still think the following statements are sufficient:

    For OLRs of type host, if the request is a host-routed request then the=
 reacting node SHOULD
    apply throttling abatement treatment to the request.

    For OLRs of type host, if the request is a realm-routed request then th=
e reacting node
    SHOULD apply diversion abatement treatment to the request.

    For OLRs of type realm, the reacting node SHOULD
    apply throttling abatement treatment to the request, independent of the=
 type (host-routed or
    realm-routed) of request.

Regards,

Steve

On 12/15/14, 2:42 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
> can you please summarize the status of #16. I'm getting lost.
>
> Regards
> Ulrich
>
> -----Original Message-----
> From: ext Ben Campbell [mailto:ben@nostrum.com]
> Sent: Thursday, December 11, 2014 8:45 PM
> To: Steve Donovan
> Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] Ulrich's suggested change #16
>
>
>> On Dec 11, 2014, at 1:36 PM, Steve Donovan  wr=
ote:
>>
>>
>> On 12/11/14, 1:03 PM, Ben Campbell wrote:
>>>> On Dec 10, 2014, at 7:06 AM, Steve Donovan  =
wrote:
>>>>
>>>> Ulrich,
>>>>
>>>> I agree with your assumptions below.  For the third one, the only time=
 it is possible, at least from a DOIC perspective, to send to another host =
is if it is a realm-routed request.  I might also change the "not overloade=
d" to "less overloaded".
>>>>
>>>> I do think the statements can be improved to differentiate between beh=
avior for host reports and realm reports.
>>>>
>>>> How about the following:
>>>>     For OLRs of type host, if the request is a host-routed request the=
n the reacting node SHOULD
>>>>     apply throttling abatement treatment to the request.
>>>>
>>>>     For OLRs of type host, If the request is a realm-routed request th=
en the reacting node
>>>>     SHOULD apply diversion abatement treatment to the request.
>>> Personally, I think that should be non-normative. Or if normative, no s=
tronger than MAY. I agree it's a good choice, but I think we can leave it t=
o the market to enforce.
>> If we make it non normative then we probably need an additional statemen=
t along the lines of "the reacting node MUST attempt to reduce traffic by t=
he amount requested in the OLR" if we don't already have it somewhere else =
in the document.
> Agreed
>
>>> I think there when we distinguish request-type, we need to consider _wh=
en_. For example, an agent may _receive_ a realm routed request but _send_ =
a host-routed request. And for a client, that may be even more subtle.
>>>
>>> This really does seem like a case of server selection.
>> I don't think it's that subtle.  If server selection hasn't already happ=
ened for a request and that request is selected for abatement and the reque=
st would have otherwise been routed to an overloaded host then the request =
should/may be diverted to another server.
>>
>> Server selection could have happened as a result of a previous transacti=
on specifying the host for subsequent transactions or by the presence of th=
e Destination-Host in the message when it arrives at an agent.  It could ha=
ve also already happened as a result of configuration.
> In the case of a client, the decision on whether to divert vs just not se=
nd a request may be heavily influenced by the client application.  (Not nec=
essarily the _Diameter_ application.)  In the case of either, a node might =
have local knowledge that a 2nd server can handle everything the first serv=
er can handle. Even if a downstream node performed server selection, a node=
 with such knowledge might override it. We don't necessarily need to talk a=
bout that sort of thing, but we should avoid language that forbids it.
>
>
>>>>     For OLRs of type realm, the reacting node SHOULD
>>>>     apply throttling abatement treatment to the request, independent o=
f the type (host-routed or
>>>>     realm-routed) of request.
>>> Again, I think this should not be normative. In this case this is prett=
y much a statement of fact--you simply cannot reasonably divert given the w=
ay that Diameter routing works. I suppose there might be a case where a nod=
e has some magical knowledge that realm2 can handle anything that realm1 ca=
n, and could divert to a different realm (which we probably still don't wan=
t to forbid.)
>>>
>>>> Regards,
>>>>
>>>> Steve
>>>>
>>>> On 12/9/14, 11:29 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>>> Steve,
>>>>> yes, then, maybe, the definition of Diversion is not correct?
>>>>> What are other people's views?
>>>>>
>>>>> My assumption was:
>>>>> If a host is overloaded, it does not help to direct traffic to that h=
ost via a different path.
>>>>> If a realm is overloaded, it does not help to direct traffic to that =
realm via a different path.
>>>>> If a host is overloaded, it helps to select an alternative (not overl=
oaded) host (if possible) and direct traffic to that host.
>>>>> If a realm is overloaded, there never is an alternative (not overload=
ed) realm to which traffic could be directed.
>>>>>
>>>>> With the current definition of Diversion, Diversion is no appropriate=
 means to address host overload and is no appropriate means to address real=
m overload. It may be ok for agent overload only.
>>>>>
>>>>> Regards
>>>>> Ulrich
>>>>>
>>>>> From: DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] On Behalf Of ext Steve Donovan
>>>>> Sent: Tuesday, December 09, 2014 3:06 PM
>>>>> To:
>>>>> dime@ietf.org
>>>>>
>>>>> Subject: [Dime] Ulrich's suggested change #16
>>>>>
>>>>> Ulrich,
>>>>>
>>>>> For your suggested change #16:
>>>>> Section 4.2.2, 5th and 6th paragraph:
>>>>> Existing text:
>>>>>     If the request is a host-routed request then the reacting node SH=
OULD
>>>>>     apply throttling abatement treatment to the request.
>>>>>       If the request is a realm-routed request then the reacting node
>>>>>     SHOULD apply diversion abatement treatment to the request.
>>>>>
>>>>> Comment: I don't think so. If the reacting node selects the server an=
d
>>>>> then detects that the selected server is overloaded and then detects =
that
>>>>> the request does not survive (i.e. is subject to abatement), then the=
 reacting
>>>>> node SHOULD apply diversion treatment (i.e. select an alternative ser=
ver if possible).
>>>>> If the reacting node does not select the server (either a. because th=
e server was
>>>>> already selected by a downstream node, or b. because the server will =
be selected
>>>>> by an upstream node) then there is no point in applying diversion and=
 the reacting
>>>>> node SHOULD apply throttling of requests that do not survive.
>>>>>
>>>>> Proposal: replace the paragraphs with:
>>>>>     If the reacting node does not select the server then it SHOULD ap=
ply
>>>>>     throttling abatement to the request.
>>>>>
>>>>>     If the reacting node selects the server then it SHOULD apply dive=
rsion
>>>>>     abatement treatment (i.e. select an alternative server if possibl=
e) to
>>>>>     the request.
>>>>> Diversion is not selecting an alternative node to handle the request.=
  Diversion is selecting an alternative route to the selected node.
>>>>>
>>>>> Whether it is appropriate to select an alternative node for a request=
 is an application decision that probably changes on a per command-code bas=
is within the application. Logic like this is outside the scope of the DOIC=
 specification.
>>>>>
>>>>> The text is correct based on the definition of diversion.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Steve
>>>>>
>>>>>
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Thu Dec 18 01:17:34 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A294E1A6F64 for ; Thu, 18 Dec 2014 01:17:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TpmAfXvIt7i for ; Thu, 18 Dec 2014 01:17:29 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA561A6EF0 for ; Thu, 18 Dec 2014 01:17:28 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBI9HQPJ012207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Dec 2014 09:17:26 GMT
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBI9HQo5011397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Dec 2014 10:17:26 +0100
Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 18 Dec 2014 10:17:26 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 10:17:26 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , Ben Campbell 
Thread-Topic: [Dime] Ulrich's suggested change @12
Thread-Index: AQHQE7ZHD23zRsD0mUyK0fJgC7jhrJyHbHpAgAFIcACAAa52UIAH+zpfgALANtA=
Date: Thu, 18 Dec 2014 09:17:25 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815235C03@DEMUMBX014.nsn-intra.net>
References: <5486FCBF.4000707@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152351D9@DEMUMBX014.nsn-intra.net> <54883F5C.1060603@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235675@DEMUMBX014.nsn-intra.net> <5489A416.2000403@usdonovans.com> <64AB1BC6-8D34-4DEB-B801-C5C127047C8C@nostrum.com> <54904C5A.2070502@usdonovans.com>
In-Reply-To: <54904C5A.2070502@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.119]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 6413
X-purgate-ID: 151667::1418894247-0000677A-1CD3F931/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/cZGdFbcUeY2TOpTU1uZbiHRlmY0
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change @12
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Dec 2014 09:17:32 -0000

Steve, Ben,

I'm in favour of 2).
Actually I do not understand 3) as it talks about overload reports, while t=
he issue is about capability anouncement.

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
Sent: Tuesday, December 16, 2014 4:15 PM
To: Ben Campbell
Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Ulrich's suggested change @12

Ben,

I see a two or three options here:

1) We add a new attribution AVP and all of the text associated with it. =20
This has obvious schedule implications.

2) We treat this the same way as we treated the issue with multiple=20
sources of OC-OLR AVPs and add text somewhere in the draft saying that=20
if agents are selecting abatement algorithms then care must be taken to=20
make sure that all agents that handle traffic for the same Diameter node=20
must select the same algorithm for all transactions involving that=20
Diameter node.

3) Number two plus reacting node behavior statements saying that the=20
reacting node SHOULD ignore overload reports for a node that has an=20
active OCS if the received overload report is of a different type then=20
stored in the active OCS.

I vote for number 3.

Regards,

Steve

On 12/11/14, 12:38 PM, Ben Campbell wrote:
>> On Dec 11, 2014, at 8:03 AM, Steve Donovan  wr=
ote:
>>
>> Ulrich,
>>
>> I see your concern.  To summarize, if we have the following configuratio=
n:
>>
>>     ----A1----
>>    /          \
>>   C            S
>>    \          /
>>     ----A2----
>>
>> And A1 indicates loss in in the OC-S-F AVP in answer messages and A2 ind=
icates rate then there is ambiguity.
>>
>> I agree, this warrants a warning statement somewhere in the document.
>>
>> If there is general agreement on this then I'll propose wording and loca=
tion.
>>
> What sort of guidance should we give here? IMO, this is a worse problem t=
han for realm reports, or at least having it for both realm and host report=
s makes it considerably worse than before. I think variations on this will =
happen for almost any Diameter network of non-trivial size.
>
> I also think it's reasonable that A1 and A2 might select different algori=
thms towards C. For example, lets say C, A1, and S all support rate, but A2=
 does not. S might select rate towards A1, but loss towards A2.
>
> If we can't handle this, I think the entire solution breaks down.
>
> I propose that the best way to handle this is to add source-attribution i=
nto OLRs, and guidance for what C should do if it gets different capabiliti=
es for the same host or realm from different paths. This _might_ also help =
solve the "different reports for same realm" problem and the "can't tell if=
 an intervening agent supports DOIC" problem.
>
>
>> Steve
>>
>> On 12/11/14, 7:31 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>> Steve,
>>>  =20
>>> yes, it's about capability announcement, and my concern in with announc=
ing the selected algorithm in answer messages (while no OLRs are sent). Mul=
tiple  agents modifying the selected algorithm in the Supported-Features AV=
Ps in answer messages may  result in ambiguity in DOIC behaviour for downst=
ream DOIC nodes.
>>>  =20
>>> Ulrich
>>>  =20
>>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
>>> Sent: Wednesday, December 10, 2014 1:41 PM
>>> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
>>> Subject: Re: [Dime] Ulrich's suggested change @12
>>>  =20
>>> Ulrich,
>>>
>>> This paragraph is talking about capability announcement.  We deal with =
the issues related to multiple sources of overload reports already elsewher=
e in the document.
>>>
>>> I still do see the need for a change.
>>>
>>> Steve
>>>
>>> On 12/9/14, 10:46 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>> Steve,
>>> I agree, my comment and proposal do not hit the mark.
>>>  =20
>>> The intention was to say that known issues exist if there are multiple =
agents on multiple paths between client and server. The agents may not be a=
ble to ensure that there is no ambiguity in DOIC behaviour for the client. =
E.g. from the client's point of view the answer to a first request (which w=
as modified by agent A1) could indicate: DOIC is supported, currenty no ove=
rload, once in overload loss will be selected; and the answer to the next r=
equest (which was modified by agent A2) could indicate: DOIC is supported, =
some?? reduction is requested using rate. The client, however, may not be p=
repared for rate.
>>>  =20
>>> Maybe a warning note could be added to say that the agent may not alway=
s be able to ensure that there is no ambiguity.
>>>  =20
>>> Ulrich
>>>  =20
>>>  =20
>>>  =20
>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donova=
n
>>> Sent: Tuesday, December 09, 2014 2:45 PM
>>> To: dime@ietf.org
>>> Subject: [Dime] Ulrich's suggested change @12
>>>  =20
>>> Ulrich,
>>>
>>> For your suggested change #12:
>>>
>>> Section 4.1.3, last paragraph:
>>> Existing text:
>>>     When making changes to the OC-Supported-Features AVP the Diameter
>>>     Agent needs to ensure that there is no ambiguity in DOIC behavior f=
or
>>>     both upstream and downstream DOIC nodes.
>>>  =20
>>> Comment: while that is true, in addition problems similar to those
>>> identified in the note in section 3.3 may result from making changes.
>>>  =20
>>> Proposal: Add the note:
>>>        Note: Known issues exist if multiple sources for overload report=
s
>>>        which apply to the same Diameter entity exist.  Reacting nodes
>>>        have no way of determining the source and, as such, will treat
>>>        them as coming from a single source.  Variance in sequence numbe=
rs
>>>        between the two sources can then cause incorrect overload
>>>        abatement treatment to be applied for indeterminate periods of
>>>        time.
>>> I don't understand how these are related.  The change to the OC-Support=
ed-Features AVP made by the agent apply only to the transaction.  In additi=
on, this paragraph doesn't mention overload reports.
>>>
>>> Regards,
>>>
>>> Steve
>>>
>>>
>>>
>>>  =20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Thu Dec 18 09:11:38 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C301A909C for ; Thu, 18 Dec 2014 09:11:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_TFn80-jOCH for ; Thu, 18 Dec 2014 09:11:20 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6A71A9077 for ; Thu, 18 Dec 2014 09:11:19 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBIHBGlm025965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Dec 2014 17:11:16 GMT
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBIHBFSd011879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Dec 2014 18:11:15 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 18:11:15 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Ben Campbell , Jouni Korhonen 
Thread-Topic: [Dime] DOIC WGLC: duration unit
Thread-Index: AQHQGbXAWRMJZc/vrkarMpVgZ93RA5yTyBAAgAAhXYCAAAObgIAADKaAgAAUDACAAAZ5AIAAQlCAgAABzgCAAT19AA==
Date: Thu, 18 Dec 2014 17:11:14 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815235C94@DEMUMBX014.nsn-intra.net>
References: <0AF415BD-4AA8-4A4F-942B-29DA6C9E417B@nostrum.com> <549193B8.6000603@usdonovans.com>  <5491B2BB.30709@usdonovans.com> <3543DB65-DFC1-4ADE-8808-7B931F325F92@nostrum.com> <5491CE28.2020205@usdonovans.com> <0E11AEDD-6E90-4D61-8759-557B8596BAFB@nostrum.com> <54920B37.4060201@gmail.com> <2BE199F8-262D-40AB-A567-A857E94B3A6A@nostrum.com>
In-Reply-To: <2BE199F8-262D-40AB-A567-A857E94B3A6A@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.102]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 1957
X-purgate-ID: 151667::1418922676-0000677A-15274DBF/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/zmw43o9OmZhnkGLis3c-5zBlSvo
Cc: "dime@ietf.org" 
Subject: Re: [Dime] DOIC WGLC: duration unit
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Dec 2014 17:11:25 -0000

Ben,

my inclination is to change back to seconds. However, seconds allow a maxim=
um value that is 1000 times higher and may be regarded unreasonably high. I=
n a previous version of the draft we had an upper limit, and maybe when goi=
ng back to seconds we should re-introduce an upper limit so that the protoc=
ol does not allow unreasonably long durations.

Ulrich


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
Sent: Thursday, December 18, 2014 12:08 AM
To: Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: duration unit


> On Dec 17, 2014, at 5:01 PM, Jouni Korhonen  wrot=
e:
>=20
> [snip]
>=20
>>> I'll step out of the argument and let someone else be champion for mill=
isecond granularity.
>>=20
>> Any other takers? Are there real use cases for sub-second precision?
>=20
> I do not really care. We changed that from seconds to milliseconds for so=
me reason.. but no not see a reason to change it back either.

I'd argue that we should make it the "right thing", regardless of whether w=
e changed it before. (Although remembering why might go far to answering my=
 last question below.)

I've describe why I think it is false precision, and can become harmful. To=
 rephrase it, choosing too small of durations will cause harm by forcing ra=
pid OLR updates (as in many per second.) These updates cause work for both =
reporting nodes and reacting nodes.=20

We could offer guidance of how to avoid that harm. Or we could choose a res=
olution that makes it harder to cause such harm in the first place. I think=
 good protocol design favors the later.

Do you disagree with the potential for harm? Or do you see some use case fo=
r sub-second precision that I've missed?


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Thu Dec 18 09:46:41 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3DA1A914F for ; Thu, 18 Dec 2014 09:46:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 209uFSz5koNj for ; Thu, 18 Dec 2014 09:46:36 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA031A1B8E for ; Thu, 18 Dec 2014 09:46:36 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBIHkYAU022568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Dec 2014 17:46:34 GMT
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBIHkWI6020343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Dec 2014 18:46:33 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.49]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 18:46:32 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Ben Campbell , Steve Donovan 
Thread-Topic: [Dime] DOIC WGLC: Changing Algorithms
Thread-Index: AQHQGbTAD7bF1y5nZ0Ktqi3JfsBjdJyTTUsAgAB56ICAACGtgIAAEAyAgAAEZQCAAA7IgIAABxKAgAAra4CAAAU7AIAACEAAgAAEPQCAAU0+QA==
Date: Thu, 18 Dec 2014 17:46:32 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815235CCD@DEMUMBX014.nsn-intra.net>
References:  <54912CBA.8080701@gmail.com> <549192FD.7060403@usdonovans.com>  <5491BCB3.30608@usdonovans.com> <0EEB7B88-CEEF-4A33-BD61-E4378F0D054D@nostrum.com> <5491CCC9.3090809@usdonovans.com> <4586B22E-3CDD-462E-8246-D55F25F4365C@nostrum.com> <5491F723.6080203@usdonovans.com>  <54920272.80508@usdonovans.com> <52901958-73B6-49FE-8DA4-A8D2F8276DD0@nostrum.com>
In-Reply-To: <52901958-73B6-49FE-8DA4-A8D2F8276DD0@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.102]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 9515
X-purgate-ID: 151667::1418924794-0000677A-61D5BC59/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/SKcioQNXl-iVWtJqw0buwu0u9Pw
Cc: "dime@ietf.org" 
Subject: Re: [Dime] DOIC WGLC: Changing Algorithms
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Dec 2014 17:46:39 -0000

Ben, Steve,

Section 4.2.1.2 says:
   A reporting node SHOULD maintain OCS entries per supported Diameter
   application, per supported (and eventually selected) Abatement
   Algorithm and per report-type.

For example, an HSS would maintain two OCSs for S6a host-type reports, one =
for loss and one for rate. When receiving a request that advertises only lo=
ss, the returned OLR would be the one according to the loss-OCS; When recei=
ving a request that advertises loss and rate, the HSS has two returned OLR =
would be the one according to the rate-OCS.

I don't see a problem when algorithm is changed at the reacting node.

Ulrich



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
Sent: Wednesday, December 17, 2014 11:39 PM
To: Steve Donovan
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: Changing Algorithms


> On Dec 17, 2014, at 4:23 PM, Steve Donovan  wro=
te:
>=20
>=20
> On 12/17/14 3:54 PM, Ben Campbell wrote:
>>> On Dec 17, 2014, at 3:35 PM, Steve Donovan  w=
rote:
>>>=20
>>>=20
>>> On 12/17/14 1:00 PM, Ben Campbell wrote:
>>>>> On Dec 17, 2014, at 12:34 PM, Steve Donovan  wrote:
>>>>>=20
>>>>>> Okay, new picture:
>>>>>>=20
>>>>>>     =20
>>>>>>> On Dec 17, 2014, at 11:26 AM, Steve Donovan 
>>>>>>>  wrote:
>>>>>>>=20
>>>>>>> Ben,
>>>>>>>=20
>>>>>>> The value of the Origin-Host matters greatly here.  In both cases, =
what S needs to know is if there is a reacting node for traffic coming from=
 C1 and if there is a reacting node for traffic coming from C2.
>>>>>>>=20
>>>>>> There is no assumption in the draft right now that we have a correla=
tion between reacting nodes and clients. That might be required for client-=
targed OLRs, but we don't have those yet.
>>>>>>=20
>>>>>> Consider a different picture. In this case, C never supports DOIC. t=
he reacting node role happens either at A1/A2 or at A3, depending on which =
flow you look at.
>>>>>>=20
>>>>>>         A1---
>>>>>>        /         \
>>>>>> C --             -------A3------S
>>>>>>        \         /
>>>>>>          A2---
>>>>>>=20
>>>>>> Now, assume the same flows, but substitute A1 for C1, A2, for C2, an=
d A3 for A. All requests now have the same origin-host.
>>>>>>=20
>>>>>> Before you say this is unrealistic: The issue is the same for any si=
tuation where one client can send traffic across multiple agents to the sam=
e destination. It doesn't matter if there is one or a million.
>>>>>>=20
>>>>> SRD> Yes, this is nasty.  With attribution S can detect the scenario.=
  I'm not sure what it does once it selects it.  This can be addressed to s=
ome degree by adding a deployment recommendation that  all agents taking on=
 reacting node functionality for a single endpoint  select the same algorit=
hm.
>>>> I think some sort of attribution is the long-term solution. Another op=
tion might be some sort of DCA state identifier, or a combination of the tw=
o. (e.g. multiple "virtual" reacting node at the same physical node.) The d=
etails will be non-trivial to figure out.
>>>>=20
>>>> But to close the loop, I think the _short_ term solution is to say tha=
t, while a reporting node should not _initiate_ a change in algorithms duri=
ng an overload condition, it must still handle the situation where the reac=
ting node forces a change. We could go further to say that reacting node al=
so should not initiate such a change, but we would have to recognize that t=
here are scenarios where that guidance cannot be enforced, and the reportin=
g node still has to handle them.
>>>>=20
>>>> We might need to think about what it means from an OCS perspective for=
 a reporting node to send OLRs with different algorithms (or potentially ot=
her capability parameters) for the "same" overload event.
>>> SRD> I think it is a better solution to stay with what we have now.  Th=
e reporting node MUST NOT change the algorithm during an active overload co=
ndition.  If a reacting node advertises support for it, the reacting node i=
s saying it will support that algorithm for the duration of any overload co=
ndition that happens prior to the reacting node changing the advertised alg=
orithm.  The change in advertised algorithm will take effect after the over=
load condition goes away.
>>>=20
>> I disagree. I don't think we want to allow the reporting node to ever in=
dicate an algorithm that was not advertised in the request. That violates n=
ormative language earlier in the section that says the selected algorithm M=
UST be one of the ones advertised in the request. It can also cause problem=
s for reacting nodes, where they get OLRs for an algorithm they don't under=
stand.
> SRD> They clearly do understand the algorithm.  They advertised it before=
 the overload report started.  We can change the normative language to cove=
r this exception.

In my first scenario, this is not true. C2 (or A2)  _never_ understood the =
rate algorithm, and never advertised support for it.

The whole point of this exercise was to show that the reporting node cannot=
, in the general case, distinguish between multiple reacting nodes with dif=
ferent capabilities, and a single reacting node that changes capabilities.

By "general case", I mean no assumption that the reacting nodes are peers w=
ith the reporting nodes, and no assumption that you can correlate origin-ho=
st values (in requests) to reacting-nodes.=20


>  I think the principle of minimizing work on an overloaded reporting node=
 is the more important principle here.  If the reacting node changes the ad=
vertised set of algorithms during an active overload condition then the ove=
rloaded reporting node will be required to send end-of-overload OLRs for th=
e previous algorithm and then send start-of-overload OLRs for the new algor=
ithm.  This seems complex at a time the overloaded node should be focusing =
on getting out of the overload condition.

Sending an OLR that the reacting node does not understand will not help you=
 get out of overload.

I don't see how this is any more complex that if you simply have multiple r=
eacting nodes with different capabilities--and I don't see how to avoid sup=
porting that case.

>>=20
>> I think that's considerably more important that restricting the reportin=
g node from changing algorithms (Which, btw, does no harm with the only alg=
orithms that we are seriously contemplating.We speculate that it might caus=
e harm for some future algorithm.)
> SRD> We already have the restriction on the reporting node.

We already have both restrictions, and they contradict. I believe the _exis=
ting_ restriction to not select an algorithm that is not advertised in the =
request is more important than the _existing_ restriction to not change alg=
orithms during an overload condition.


>>=20
>> Remember, this is not just about a single reacting node changing it's ca=
pabilities, it's also about multiple reacting nodes with different capabili=
ties. We can't disallow one without disallowing the other.
> SRD> Multiple reacting nodes with different capabilities is all the more =
reason to hold things constant during an overload condition.

I don't follow that. You seem to be pushing towards using the same algorith=
m for all reacting nodes once an overload condition starts. Is that your in=
tent?  (Given the possibility that some future reacting node will only supp=
ort "loss", that "same algorithm" would pretty much always need to be loss.=
)

>  I'm not proposing disallowing reacting nodes from changing the set of ca=
pabilities, I'm proposing that these changes don't take effect while there =
is an active overload condition.

The problem exists even if no reacting node ever changes its capabilities.

>>=20
>>=20
>>> SRD> I don't think we need to update the OCS in this document to handle=
 multiple algorithms.  This can be done in the extension drafts.  We might =
want to make it clear, as it appears it isn't already, that a reacting node=
 might need to support multiple algorithms at the same time.
>> Do you mean reacting or reporting node in the last sentence? Assuming yo=
u mean it as written, the problem is not that a reacting node may need to s=
upport multiple algorithms at the same time. It's that it may get OLRs that=
 it cannot act upon because it doesn't support the algorithm.
> SRD> I meant reporting nodes.
>>=20
>> If, otoh, you meant reporting node, I don't understand how a reporting n=
ode can have multiple algorithms for the same overload event, without refle=
cting that possibility in the OCS.
> SRD> Yes, it will need to be reflected in the OCS.  We don't have multipl=
e algorithms now so it isn't needed now.  I'm saying we might want to say i=
t might me needed in the future.

I'd rather not make each new algorithm redefine the basic structure of OCS.

But, if you recall, my point was to say we need to _think_ about how this i=
mpacts OCS, not that we necessarily need to change anything. Are you oppose=
d to thinking about it? (And no, I don't think this short exchange quite co=
unts as that.)

>>=20
>>=20
>>=20
>>>>=20
>>=20
>=20

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Thu Dec 18 15:47:13 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DAA1A923B for ; Thu, 18 Dec 2014 15:47:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5PdTf7T6hc8 for ; Thu, 18 Dec 2014 15:47:10 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598671A9239 for ; Thu, 18 Dec 2014 15:47:10 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBINl6Nj061845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2014 17:47:07 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815235C94@DEMUMBX014.nsn-intra.net>
Date: Thu, 18 Dec 2014 17:47:06 -0600
X-Mao-Original-Outgoing-Id: 440639226.127802-4b17089089755a49502fa37441915134
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <0AF415BD-4AA8-4A4F-942B-29DA6C9E417B@nostrum.com> <549193B8.6000603@usdonovans.com>  <5491B2BB.30709@usdonovans.com> <3543DB65-DFC1-4ADE-8808-7B931F325F92@nostrum.com> <5491CE28.2020205@usdonovans.com> <0E11AEDD-6E90-4D61-8759-557B8596BAFB@nostrum.com> <54920B37.4060201@gmail.com> <2BE199F8-262D-40AB-A567-A857E94B3A6A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D900066815235C94@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/p1oBckXQ0Rk6OQxMB_DQYm-Cu0Y
Cc: "dime@ietf.org" 
Subject: Re: [Dime] DOIC WGLC: duration unit
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Dec 2014 23:47:11 -0000

Hi Ulrich,

You bring up a good point that we need to document the limits, or at =
least describe the implications of choosing to long or short of a =
duration either way. I suspect 1s is still too short for most =
situations, and  ( 2^32 - 1 / 1000 )s is probably still too long.

(Don't get me wrong; I still think millisecond resolution for this is =
silly.)

Thanks!

Ben.

> On Dec 18, 2014, at 11:11 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:
>=20
> Ben,
>=20
> my inclination is to change back to seconds. However, seconds allow a =
maximum value that is 1000 times higher and may be regarded unreasonably =
high. In a previous version of the draft we had an upper limit, and =
maybe when going back to seconds we should re-introduce an upper limit =
so that the protocol does not allow unreasonably long durations.
>=20
> Ulrich
>=20
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben =
Campbell
> Sent: Thursday, December 18, 2014 12:08 AM
> To: Jouni Korhonen
> Cc: dime@ietf.org
> Subject: Re: [Dime] DOIC WGLC: duration unit
>=20
>=20
>> On Dec 17, 2014, at 5:01 PM, Jouni Korhonen  =
wrote:
>>=20
>> [snip]
>>=20
>>>> I'll step out of the argument and let someone else be champion for =
millisecond granularity.
>>>=20
>>> Any other takers? Are there real use cases for sub-second precision?
>>=20
>> I do not really care. We changed that from seconds to milliseconds =
for some reason.. but no not see a reason to change it back either.
>=20
> I'd argue that we should make it the "right thing", regardless of =
whether we changed it before. (Although remembering why might go far to =
answering my last question below.)
>=20
> I've describe why I think it is false precision, and can become =
harmful. To rephrase it, choosing too small of durations will cause harm =
by forcing rapid OLR updates (as in many per second.) These updates =
cause work for both reporting nodes and reacting nodes.=20
>=20
> We could offer guidance of how to avoid that harm. Or we could choose =
a resolution that makes it harder to cause such harm in the first place. =
I think good protocol design favors the later.
>=20
> Do you disagree with the potential for harm? Or do you see some use =
case for sub-second precision that I've missed?
>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Dec 19 10:07:39 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF47F1ACCF9 for ; Fri, 19 Dec 2014 10:07:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Awvyco3fcSt for ; Fri, 19 Dec 2014 10:07:34 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909111ACCFD for ; Fri, 19 Dec 2014 10:07:31 -0800 (PST)
X-AuditID: c1b4fb30-f79d66d00000744c-c5-549469616b55
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8B.83.29772.16964945; Fri, 19 Dec 2014 19:07:29 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.101]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 19:07:29 +0100
From: Maria Cruz Bartolome 
To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Steve Donovan" , ext Ben Campbell 
Thread-Topic: [Dime] Ulrich's suggested change #16
Thread-Index: AQHQE7lXyc+G3J0M1EW8kbPFxFEQNZyHfq1QgANENfD///h3AIAAAngAgAZo/cCAASFYAIAC0YbQgAIsHfA=
Date: Fri, 19 Dec 2014 18:07:28 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209895065@ESESSMB101.ericsson.se>
References: <548701E1.3060502@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235234@DEMUMBX014.nsn-intra.net> <54884556.90108@usdonovans.com> <9B6C0FB1-B3D5-4050-B79D-E429A440CE79@nostrum.com> <5489F246.5040801@usdonovans.com> <8D4FC2F7-30F8-41AF-9F19-209BB48FCB9D@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668152359A7@DEMUMBX014.nsn-intra.net> <549047A0.4060503@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235BEF@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815235BEF@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3Rjcxc0qIwdEJuhbzO0+zW8ztXcFm saGJx2Ld2xVMDiweS5b8ZPKYtfMJi8fP9VfZPVa97WMNYInisklJzcksSy3St0vgylj/aT9b wVz3io6ni5gaGGdYdjFyckgImEh8mruTCcIWk7hwbz0biC0kcIRRYuLjGgh7CaPE1FVWIDab gJ3EpdMvgOq5OEQEJjFKdPX+YwZJMAsoS8ze8YAdxBYWMJS4c+klK4gtImAkMfPkfTYIO0mi rekbWJxFQFWi9fdMsMW8Ar4SSycfYgYZKiRwmVni7vQ1YIM4BQIkWk7dBWtgBLru+6k1TBDL xCVuPZkPdbWAxJI955khbFGJl4//AdVzANmKEsv75SDKdSQW7P7EBmFrSyxb+JoZYq+gxMmZ T1gmMIrNQjJ1FpKWWUhaZiFpWcDIsopRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMMoObvlt sIPx5XPHQ4wCHIxKPLwbpkwOEWJNLCuuzD3EKM3BoiTOu/DcvGAhgfTEktTs1NSC1KL4otKc 1OJDjEwcnFINjPpCH6ctYn8V/91R+ObiCwyP0uyCvxzdV1pVZnQnZ94kJcbDu6cq3r4sPvtm xSXRZdzz1J9aMlxcOK32z+GgL3rPWKwOXXyyXFg87OrWkJS6Rf9t3c+k7TzJvFyGl/+LSZTU iu5NJ9ae2/Nxlffk8guuS9rfJ1e/cN67x281Q+uqzKavNnphltOUWIozEg21mIuKEwHmbFb6 kwIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/yUl8wgXqwILVz-AcSxnj7nZZr9g
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #16
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Dec 2014 18:07:37 -0000

Hello all,

I agree with Ulrich proposal.
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: jueves, 18 de diciembre de 2014 10:10
To: ext Steve Donovan; ext Ben Campbell
Cc: dime@ietf.org
Subject: Re: [Dime] Ulrich's suggested change #16

Steve,

I'm still not convinced.

Another proposal:

If diversion abatement treatment is possible (i.e. a different path for the=
 request can be selected where the overloaded node is not part of the diffe=
rent path), then the reacting node SHOULD apply diversion abatement treatme=
nt to the request. Otherwise the reacting node SHOULD apply throttling abat=
ement treatment to the request.=20

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, December 16, 2014 3:54 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: dime@ietf.org
Subject: Re: [Dime] Ulrich's suggested change #16

Ulrich,

I still think the following statements are sufficient:

    For OLRs of type host, if the request is a host-routed request then the=
 reacting node SHOULD
    apply throttling abatement treatment to the request.

    For OLRs of type host, if the request is a realm-routed request then th=
e reacting node
    SHOULD apply diversion abatement treatment to the request.

    For OLRs of type realm, the reacting node SHOULD
    apply throttling abatement treatment to the request, independent of the=
 type (host-routed or
    realm-routed) of request.

Regards,

Steve

On 12/15/14, 2:42 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
> can you please summarize the status of #16. I'm getting lost.
>
> Regards
> Ulrich
>
> -----Original Message-----
> From: ext Ben Campbell [mailto:ben@nostrum.com]
> Sent: Thursday, December 11, 2014 8:45 PM
> To: Steve Donovan
> Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] Ulrich's suggested change #16
>
>
>> On Dec 11, 2014, at 1:36 PM, Steve Donovan  wr=
ote:
>>
>>
>> On 12/11/14, 1:03 PM, Ben Campbell wrote:
>>>> On Dec 10, 2014, at 7:06 AM, Steve Donovan  =
wrote:
>>>>
>>>> Ulrich,
>>>>
>>>> I agree with your assumptions below.  For the third one, the only time=
 it is possible, at least from a DOIC perspective, to send to another host =
is if it is a realm-routed request.  I might also change the "not overloade=
d" to "less overloaded".
>>>>
>>>> I do think the statements can be improved to differentiate between beh=
avior for host reports and realm reports.
>>>>
>>>> How about the following:
>>>>     For OLRs of type host, if the request is a host-routed request the=
n the reacting node SHOULD
>>>>     apply throttling abatement treatment to the request.
>>>>
>>>>     For OLRs of type host, If the request is a realm-routed request th=
en the reacting node
>>>>     SHOULD apply diversion abatement treatment to the request.
>>> Personally, I think that should be non-normative. Or if normative, no s=
tronger than MAY. I agree it's a good choice, but I think we can leave it t=
o the market to enforce.
>> If we make it non normative then we probably need an additional statemen=
t along the lines of "the reacting node MUST attempt to reduce traffic by t=
he amount requested in the OLR" if we don't already have it somewhere else =
in the document.
> Agreed
>
>>> I think there when we distinguish request-type, we need to consider _wh=
en_. For example, an agent may _receive_ a realm routed request but _send_ =
a host-routed request. And for a client, that may be even more subtle.
>>>
>>> This really does seem like a case of server selection.
>> I don't think it's that subtle.  If server selection hasn't already happ=
ened for a request and that request is selected for abatement and the reque=
st would have otherwise been routed to an overloaded host then the request =
should/may be diverted to another server.
>>
>> Server selection could have happened as a result of a previous transacti=
on specifying the host for subsequent transactions or by the presence of th=
e Destination-Host in the message when it arrives at an agent.  It could ha=
ve also already happened as a result of configuration.
> In the case of a client, the decision on whether to divert vs just not se=
nd a request may be heavily influenced by the client application.  (Not nec=
essarily the _Diameter_ application.)  In the case of either, a node might =
have local knowledge that a 2nd server can handle everything the first serv=
er can handle. Even if a downstream node performed server selection, a node=
 with such knowledge might override it. We don't necessarily need to talk a=
bout that sort of thing, but we should avoid language that forbids it.
>
>
>>>>     For OLRs of type realm, the reacting node SHOULD
>>>>     apply throttling abatement treatment to the request, independent o=
f the type (host-routed or
>>>>     realm-routed) of request.
>>> Again, I think this should not be normative. In this case this is=20
>>> pretty much a statement of fact--you simply cannot reasonably divert=20
>>> given the way that Diameter routing works. I suppose there might be=20
>>> a case where a node has some magical knowledge that realm2 can=20
>>> handle anything that realm1 can, and could divert to a different=20
>>> realm (which we probably still don't want to forbid.)
>>>
>>>> Regards,
>>>>
>>>> Steve
>>>>
>>>> On 12/9/14, 11:29 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>>> Steve,
>>>>> yes, then, maybe, the definition of Diversion is not correct?
>>>>> What are other people's views?
>>>>>
>>>>> My assumption was:
>>>>> If a host is overloaded, it does not help to direct traffic to that h=
ost via a different path.
>>>>> If a realm is overloaded, it does not help to direct traffic to that =
realm via a different path.
>>>>> If a host is overloaded, it helps to select an alternative (not overl=
oaded) host (if possible) and direct traffic to that host.
>>>>> If a realm is overloaded, there never is an alternative (not overload=
ed) realm to which traffic could be directed.
>>>>>
>>>>> With the current definition of Diversion, Diversion is no appropriate=
 means to address host overload and is no appropriate means to address real=
m overload. It may be ok for agent overload only.
>>>>>
>>>>> Regards
>>>>> Ulrich
>>>>>
>>>>> From: DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] On Behalf Of ext Steve Donovan
>>>>> Sent: Tuesday, December 09, 2014 3:06 PM
>>>>> To:
>>>>> dime@ietf.org
>>>>>
>>>>> Subject: [Dime] Ulrich's suggested change #16
>>>>>
>>>>> Ulrich,
>>>>>
>>>>> For your suggested change #16:
>>>>> Section 4.2.2, 5th and 6th paragraph:
>>>>> Existing text:
>>>>>     If the request is a host-routed request then the reacting node SH=
OULD
>>>>>     apply throttling abatement treatment to the request.
>>>>>       If the request is a realm-routed request then the reacting node
>>>>>     SHOULD apply diversion abatement treatment to the request.
>>>>>
>>>>> Comment: I don't think so. If the reacting node selects the server=20
>>>>> and then detects that the selected server is overloaded and then=20
>>>>> detects that the request does not survive (i.e. is subject to=20
>>>>> abatement), then the reacting node SHOULD apply diversion treatment (=
i.e. select an alternative server if possible).
>>>>> If the reacting node does not select the server (either a. because=20
>>>>> the server was already selected by a downstream node, or b.=20
>>>>> because the server will be selected by an upstream node) then=20
>>>>> there is no point in applying diversion and the reacting node SHOULD =
apply throttling of requests that do not survive.
>>>>>
>>>>> Proposal: replace the paragraphs with:
>>>>>     If the reacting node does not select the server then it SHOULD ap=
ply
>>>>>     throttling abatement to the request.
>>>>>
>>>>>     If the reacting node selects the server then it SHOULD apply dive=
rsion
>>>>>     abatement treatment (i.e. select an alternative server if possibl=
e) to
>>>>>     the request.
>>>>> Diversion is not selecting an alternative node to handle the request.=
  Diversion is selecting an alternative route to the selected node.
>>>>>
>>>>> Whether it is appropriate to select an alternative node for a request=
 is an application decision that probably changes on a per command-code bas=
is within the application. Logic like this is outside the scope of the DOIC=
 specification.
>>>>>
>>>>> The text is correct based on the definition of diversion.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Steve
>>>>>
>>>>>
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Dec 19 10:09:14 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5103A1ACCF9 for ; Fri, 19 Dec 2014 10:09:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gkn5DlNMLOUW for ; Fri, 19 Dec 2014 10:09:09 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 020951A8A66 for ; Fri, 19 Dec 2014 10:08:55 -0800 (PST)
X-AuditID: c1b4fb30-f79d66d00000744c-a3-549469b54bae
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 99.C3.29772.5B964945; Fri, 19 Dec 2014 19:08:54 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.101]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 19:08:53 +0100
From: Maria Cruz Bartolome 
To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Steve Donovan" , Ben Campbell 
Thread-Topic: [Dime] Ulrich's suggested change @12
Thread-Index: AQHQE7ZHD23zRsD0mUyK0fJgC7jhrJyHbHpAgAFIcACAAa52UIAH+zpfgALANtCAAidCsA==
Date: Fri, 19 Dec 2014 18:08:52 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920989507A@ESESSMB101.ericsson.se>
References: <5486FCBF.4000707@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152351D9@DEMUMBX014.nsn-intra.net> <54883F5C.1060603@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235675@DEMUMBX014.nsn-intra.net> <5489A416.2000403@usdonovans.com> <64AB1BC6-8D34-4DEB-B801-C5C127047C8C@nostrum.com> <54904C5A.2070502@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235C03@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815235C03@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3Rndb5pQQgy+n2Czmd55mt5jbu4LN YkMTj8W6tyuYHFg8liz5yeQxa+cTFo+f66+ye6x628cawBLFZZOSmpNZllqkb5fAlbHl3EbG gv+mFf8bb7I2MB7V6mLk5JAQMJGYOvcIC4QtJnHh3nq2LkYuDiGBI4wSq/evZoJwljBKfDm1 nhWkik3ATuLS6RdgCRGBPkaJB60fmUASzALKErN3PGAHsYUFDCWOrr4I1iAiYCQx+egaRgg7 TGLqz7Ng9SwCqhKHjs8HWsfBwSvgK7FphzhIWEhgAbPEu/XcIDanQIDE0VMvwa5jBLru+6k1 UKvEJW49mc8EcbWAxJI955khbFGJl4//sYKMlBBQlFjeLwdRriOxYPcnNghbW2LZwtdg5bwC ghInZz5hmcAoNgvJ1FlIWmYhaZmFpGUBI8sqRtHi1OKk3HQjI73Uoszk4uL8PL281JJNjMAo O7jlt8EOxpfPHQ8xCnAwKvHwbpgyOUSINbGsuDL3EKM0B4uSOO/Cc/OChQTSE0tSs1NTC1KL 4otKc1KLDzEycXBKNTB27Mn+2HvVfaN8zR0/r60zDxvEsMsWGcz5neByJnFjRqn3XnUxV6v7 rg2BSqtr7RfyvctuN/7acDa2ZtavD+un/tt9La91yYXY9ZPVWjfG7VG1TNFxfcky3UjBSEwx ZtPJVq/Nm64ucBT/4efJah7/MPj384+zTton3D1j4SNw2SlsisBqk1QlluKMREMt5qLiRABb JsoJkwIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-vk62WY5W01tYutsslBLW1lBY5w
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change @12
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Dec 2014 18:09:12 -0000

Dear all,

In favor of 2),  unless 3) could be clarified, not clear to me neither.
Thanks
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: jueves, 18 de diciembre de 2014 10:17
To: ext Steve Donovan; Ben Campbell
Cc: dime@ietf.org
Subject: Re: [Dime] Ulrich's suggested change @12

Steve, Ben,

I'm in favour of 2).
Actually I do not understand 3) as it talks about overload reports, while t=
he issue is about capability anouncement.

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, December 16, 2014 4:15 PM
To: Ben Campbell
Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Ulrich's suggested change @12

Ben,

I see a two or three options here:

1) We add a new attribution AVP and all of the text associated with it. =20
This has obvious schedule implications.

2) We treat this the same way as we treated the issue with multiple sources=
 of OC-OLR AVPs and add text somewhere in the draft saying that if agents a=
re selecting abatement algorithms then care must be taken to make sure that=
 all agents that handle traffic for the same Diameter node must select the =
same algorithm for all transactions involving that Diameter node.

3) Number two plus reacting node behavior statements saying that the reacti=
ng node SHOULD ignore overload reports for a node that has an active OCS if=
 the received overload report is of a different type then stored in the act=
ive OCS.

I vote for number 3.

Regards,

Steve

On 12/11/14, 12:38 PM, Ben Campbell wrote:
>> On Dec 11, 2014, at 8:03 AM, Steve Donovan  wr=
ote:
>>
>> Ulrich,
>>
>> I see your concern.  To summarize, if we have the following configuratio=
n:
>>
>>     ----A1----
>>    /          \
>>   C            S
>>    \          /
>>     ----A2----
>>
>> And A1 indicates loss in in the OC-S-F AVP in answer messages and A2 ind=
icates rate then there is ambiguity.
>>
>> I agree, this warrants a warning statement somewhere in the document.
>>
>> If there is general agreement on this then I'll propose wording and loca=
tion.
>>
> What sort of guidance should we give here? IMO, this is a worse problem t=
han for realm reports, or at least having it for both realm and host report=
s makes it considerably worse than before. I think variations on this will =
happen for almost any Diameter network of non-trivial size.
>
> I also think it's reasonable that A1 and A2 might select different algori=
thms towards C. For example, lets say C, A1, and S all support rate, but A2=
 does not. S might select rate towards A1, but loss towards A2.
>
> If we can't handle this, I think the entire solution breaks down.
>
> I propose that the best way to handle this is to add source-attribution i=
nto OLRs, and guidance for what C should do if it gets different capabiliti=
es for the same host or realm from different paths. This _might_ also help =
solve the "different reports for same realm" problem and the "can't tell if=
 an intervening agent supports DOIC" problem.
>
>
>> Steve
>>
>> On 12/11/14, 7:31 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>> Steve,
>>>  =20
>>> yes, it's about capability announcement, and my concern in with announc=
ing the selected algorithm in answer messages (while no OLRs are sent). Mul=
tiple  agents modifying the selected algorithm in the Supported-Features AV=
Ps in answer messages may  result in ambiguity in DOIC behaviour for downst=
ream DOIC nodes.
>>>  =20
>>> Ulrich
>>>  =20
>>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
>>> Sent: Wednesday, December 10, 2014 1:41 PM
>>> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
>>> Subject: Re: [Dime] Ulrich's suggested change @12
>>>  =20
>>> Ulrich,
>>>
>>> This paragraph is talking about capability announcement.  We deal with =
the issues related to multiple sources of overload reports already elsewher=
e in the document.
>>>
>>> I still do see the need for a change.
>>>
>>> Steve
>>>
>>> On 12/9/14, 10:46 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>> Steve,
>>> I agree, my comment and proposal do not hit the mark.
>>>  =20
>>> The intention was to say that known issues exist if there are multiple =
agents on multiple paths between client and server. The agents may not be a=
ble to ensure that there is no ambiguity in DOIC behaviour for the client. =
E.g. from the client's point of view the answer to a first request (which w=
as modified by agent A1) could indicate: DOIC is supported, currenty no ove=
rload, once in overload loss will be selected; and the answer to the next r=
equest (which was modified by agent A2) could indicate: DOIC is supported, =
some?? reduction is requested using rate. The client, however, may not be p=
repared for rate.
>>>  =20
>>> Maybe a warning note could be added to say that the agent may not alway=
s be able to ensure that there is no ambiguity.
>>>  =20
>>> Ulrich
>>>  =20
>>>  =20
>>>  =20
>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve=20
>>> Donovan
>>> Sent: Tuesday, December 09, 2014 2:45 PM
>>> To: dime@ietf.org
>>> Subject: [Dime] Ulrich's suggested change @12
>>>  =20
>>> Ulrich,
>>>
>>> For your suggested change #12:
>>>
>>> Section 4.1.3, last paragraph:
>>> Existing text:
>>>     When making changes to the OC-Supported-Features AVP the Diameter
>>>     Agent needs to ensure that there is no ambiguity in DOIC behavior f=
or
>>>     both upstream and downstream DOIC nodes.
>>>  =20
>>> Comment: while that is true, in addition problems similar to those=20
>>> identified in the note in section 3.3 may result from making changes.
>>>  =20
>>> Proposal: Add the note:
>>>        Note: Known issues exist if multiple sources for overload report=
s
>>>        which apply to the same Diameter entity exist.  Reacting nodes
>>>        have no way of determining the source and, as such, will treat
>>>        them as coming from a single source.  Variance in sequence numbe=
rs
>>>        between the two sources can then cause incorrect overload
>>>        abatement treatment to be applied for indeterminate periods of
>>>        time.
>>> I don't understand how these are related.  The change to the OC-Support=
ed-Features AVP made by the agent apply only to the transaction.  In additi=
on, this paragraph doesn't mention overload reports.
>>>
>>> Regards,
>>>
>>> Steve
>>>
>>>
>>>
>>>  =20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Dec 19 11:58:40 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D326A1A6FD4 for ; Fri, 19 Dec 2014 11:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUZagySXtPbX for ; Fri, 19 Dec 2014 11:58:19 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7DF1A6FB5 for ; Fri, 19 Dec 2014 11:58:19 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBJJwGM8068248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Dec 2014 13:58:17 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815235CCD@DEMUMBX014.nsn-intra.net>
Date: Fri, 19 Dec 2014 13:58:16 -0600
X-Mao-Original-Outgoing-Id: 440711896.365872-f04a2b4c67eaa4e11322b459a03a83ec
Content-Transfer-Encoding: quoted-printable
Message-Id: <8FB9C2A7-7D61-4D46-9808-AD17DB61B8CE@nostrum.com>
References:  <54912CBA.8080701@gmail.com> <549192FD.7060403@usdonovans.com>  <5491BCB3.30608@usdonovans.com> <0EEB7B88-CEEF-4A33-BD61-E4378F0D054D@nostrum.com> <5491CCC9.3090809@usdonovans.com> <4586B22E-3CDD-462E-8246-D55F25F4365C@nostrum.com> <5491F723.6080203@usdonovans.com>  <54920272.80508@usdonovans.com> <52901958-73B6-49FE-8DA4-A8D2F8276DD0@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D900066815235CCD@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/D2jY9u0s-d7ddrU49i37VtdB7Nc
Cc: "dime@ietf.org" 
Subject: Re: [Dime] DOIC WGLC: Changing Algorithms
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Dec 2014 19:58:25 -0000

Steve and I had an offline discussion, and I think we agree that the =
reporting node can be forced to change algorithms during an active =
overload condition, if it gets a request that doesn't advertise support =
for the active algorithm.

We currently have text forbidding the reporting node from changing =
algorithms during an active overload condition, without making this =
exception. We assume that we still want to otherwise keep the limitation =
on algorithm changes during overload. Here's a concrete proposal:

In 4.1.2:

Old:

For an ongoing overload condition, a reporting node MUST NOT change the =
selected algorithm during the period of time that it is in an overload =
condition and, as a result, is sending OC-OLR AVPs in answer messages.

New:

For an ongoing overload condition, a reporting node MUST NOT initiate a =
change to the selected algorithm during the period of time that it is in =
an overload condition and, as a result, is sending OC-OLR AVPs in answer =
messages. This rule does not affect the case where the =
OC-Supported-Features in a new request matching the OLR does not =
advertise support for the current algorithm, in which case the reporting =
node would be forced to change algorithms. However, this rule does =
constrain the reporting node from changing algorithms simply because the =
reacting node advertises other algorithms in addition to one currently =
in use.

Added text in 4.1.1:

If a reacting node is using an abatement algorithm to abate traffic due =
to an active OLR from a reporting node, the reacting node SHOULD =
continue to advertise support for that algorithm in future requests that =
match the OLR, until the overload condition is terminated.


> On Dec 18, 2014, at 11:46 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:
>=20
> Ben, Steve,
>=20
> Section 4.2.1.2 says:
>   A reporting node SHOULD maintain OCS entries per supported Diameter
>   application, per supported (and eventually selected) Abatement
>   Algorithm and per report-type.
>=20
> For example, an HSS would maintain two OCSs for S6a host-type reports, =
one for loss and one for rate. When receiving a request that advertises =
only loss, the returned OLR would be the one according to the loss-OCS; =
When receiving a request that advertises loss and rate, the HSS has two =
returned OLR would be the one according to the rate-OCS.
>=20
> I don't see a problem when algorithm is changed at the reacting node.
>=20
> Ulrich
>=20
>=20
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben =
Campbell
> Sent: Wednesday, December 17, 2014 11:39 PM
> To: Steve Donovan
> Cc: dime@ietf.org
> Subject: Re: [Dime] DOIC WGLC: Changing Algorithms
>=20
>=20
>> On Dec 17, 2014, at 4:23 PM, Steve Donovan  =
wrote:
>>=20
>>=20
>> On 12/17/14 3:54 PM, Ben Campbell wrote:
>>>> On Dec 17, 2014, at 3:35 PM, Steve Donovan =
 wrote:
>>>>=20
>>>>=20
>>>> On 12/17/14 1:00 PM, Ben Campbell wrote:
>>>>>> On Dec 17, 2014, at 12:34 PM, Steve Donovan =
 wrote:
>>>>>>=20
>>>>>>> Okay, new picture:
>>>>>>>=20
>>>>>>>=20
>>>>>>>> On Dec 17, 2014, at 11:26 AM, Steve Donovan =

>>>>>>>> wrote:
>>>>>>>>=20
>>>>>>>> Ben,
>>>>>>>>=20
>>>>>>>> The value of the Origin-Host matters greatly here.  In both =
cases, what S needs to know is if there is a reacting node for traffic =
coming from C1 and if there is a reacting node for traffic coming from =
C2.
>>>>>>>>=20
>>>>>>> There is no assumption in the draft right now that we have a =
correlation between reacting nodes and clients. That might be required =
for client-targed OLRs, but we don't have those yet.
>>>>>>>=20
>>>>>>> Consider a different picture. In this case, C never supports =
DOIC. the reacting node role happens either at A1/A2 or at A3, depending =
on which flow you look at.
>>>>>>>=20
>>>>>>>        A1---
>>>>>>>       /         \
>>>>>>> C --             -------A3------S
>>>>>>>       \         /
>>>>>>>         A2---
>>>>>>>=20
>>>>>>> Now, assume the same flows, but substitute A1 for C1, A2, for =
C2, and A3 for A. All requests now have the same origin-host.
>>>>>>>=20
>>>>>>> Before you say this is unrealistic: The issue is the same for =
any situation where one client can send traffic across multiple agents =
to the same destination. It doesn't matter if there is one or a million.
>>>>>>>=20
>>>>>> SRD> Yes, this is nasty.  With attribution S can detect the =
scenario.  I'm not sure what it does once it selects it.  This can be =
addressed to some degree by adding a deployment recommendation that  all =
agents taking on reacting node functionality for a single endpoint  =
select the same algorithm.
>>>>> I think some sort of attribution is the long-term solution. =
Another option might be some sort of DCA state identifier, or a =
combination of the two. (e.g. multiple "virtual" reacting node at the =
same physical node.) The details will be non-trivial to figure out.
>>>>>=20
>>>>> But to close the loop, I think the _short_ term solution is to say =
that, while a reporting node should not _initiate_ a change in =
algorithms during an overload condition, it must still handle the =
situation where the reacting node forces a change. We could go further =
to say that reacting node also should not initiate such a change, but we =
would have to recognize that there are scenarios where that guidance =
cannot be enforced, and the reporting node still has to handle them.
>>>>>=20
>>>>> We might need to think about what it means from an OCS perspective =
for a reporting node to send OLRs with different algorithms (or =
potentially other capability parameters) for the "same" overload event.
>>>> SRD> I think it is a better solution to stay with what we have now. =
 The reporting node MUST NOT change the algorithm during an active =
overload condition.  If a reacting node advertises support for it, the =
reacting node is saying it will support that algorithm for the duration =
of any overload condition that happens prior to the reacting node =
changing the advertised algorithm.  The change in advertised algorithm =
will take effect after the overload condition goes away.
>>>>=20
>>> I disagree. I don't think we want to allow the reporting node to =
ever indicate an algorithm that was not advertised in the request. That =
violates normative language earlier in the section that says the =
selected algorithm MUST be one of the ones advertised in the request. It =
can also cause problems for reacting nodes, where they get OLRs for an =
algorithm they don't understand.
>> SRD> They clearly do understand the algorithm.  They advertised it =
before the overload report started.  We can change the normative =
language to cover this exception.
>=20
> In my first scenario, this is not true. C2 (or A2)  _never_ understood =
the rate algorithm, and never advertised support for it.
>=20
> The whole point of this exercise was to show that the reporting node =
cannot, in the general case, distinguish between multiple reacting nodes =
with different capabilities, and a single reacting node that changes =
capabilities.
>=20
> By "general case", I mean no assumption that the reacting nodes are =
peers with the reporting nodes, and no assumption that you can correlate =
origin-host values (in requests) to reacting-nodes.=20
>=20
>=20
>> I think the principle of minimizing work on an overloaded reporting =
node is the more important principle here.  If the reacting node changes =
the advertised set of algorithms during an active overload condition =
then the overloaded reporting node will be required to send =
end-of-overload OLRs for the previous algorithm and then send =
start-of-overload OLRs for the new algorithm.  This seems complex at a =
time the overloaded node should be focusing on getting out of the =
overload condition.
>=20
> Sending an OLR that the reacting node does not understand will not =
help you get out of overload.
>=20
> I don't see how this is any more complex that if you simply have =
multiple reacting nodes with different capabilities--and I don't see how =
to avoid supporting that case.
>=20
>>>=20
>>> I think that's considerably more important that restricting the =
reporting node from changing algorithms (Which, btw, does no harm with =
the only algorithms that we are seriously contemplating.We speculate =
that it might cause harm for some future algorithm.)
>> SRD> We already have the restriction on the reporting node.
>=20
> We already have both restrictions, and they contradict. I believe the =
_existing_ restriction to not select an algorithm that is not advertised =
in the request is more important than the _existing_ restriction to not =
change algorithms during an overload condition.
>=20
>=20
>>>=20
>>> Remember, this is not just about a single reacting node changing =
it's capabilities, it's also about multiple reacting nodes with =
different capabilities. We can't disallow one without disallowing the =
other.
>> SRD> Multiple reacting nodes with different capabilities is all the =
more reason to hold things constant during an overload condition.
>=20
> I don't follow that. You seem to be pushing towards using the same =
algorithm for all reacting nodes once an overload condition starts. Is =
that your intent?  (Given the possibility that some future reacting node =
will only support "loss", that "same algorithm" would pretty much always =
need to be loss.)
>=20
>> I'm not proposing disallowing reacting nodes from changing the set of =
capabilities, I'm proposing that these changes don't take effect while =
there is an active overload condition.
>=20
> The problem exists even if no reacting node ever changes its =
capabilities.
>=20
>>>=20
>>>=20
>>>> SRD> I don't think we need to update the OCS in this document to =
handle multiple algorithms.  This can be done in the extension drafts.  =
We might want to make it clear, as it appears it isn't already, that a =
reacting node might need to support multiple algorithms at the same =
time.
>>> Do you mean reacting or reporting node in the last sentence? =
Assuming you mean it as written, the problem is not that a reacting node =
may need to support multiple algorithms at the same time. It's that it =
may get OLRs that it cannot act upon because it doesn't support the =
algorithm.
>> SRD> I meant reporting nodes.
>>>=20
>>> If, otoh, you meant reporting node, I don't understand how a =
reporting node can have multiple algorithms for the same overload event, =
without reflecting that possibility in the OCS.
>> SRD> Yes, it will need to be reflected in the OCS.  We don't have =
multiple algorithms now so it isn't needed now.  I'm saying we might =
want to say it might me needed in the future.
>=20
> I'd rather not make each new algorithm redefine the basic structure of =
OCS.
>=20
> But, if you recall, my point was to say we need to _think_ about how =
this impacts OCS, not that we necessarily need to change anything. Are =
you opposed to thinking about it? (And no, I don't think this short =
exchange quite counts as that.)
>=20
>>>=20
>>>=20
>>>=20
>>>>>=20
>>>=20
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Dec 19 13:45:26 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306C01AC3D0 for ; Fri, 19 Dec 2014 13:45:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSpf2nhbvl-S for ; Fri, 19 Dec 2014 13:45:22 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17E241A1BD2 for ; Fri, 19 Dec 2014 13:45:22 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBJLjKBk077496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Dec 2014 15:45:21 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5491AEC7.8070307@usdonovans.com>
Date: Fri, 19 Dec 2014 15:45:20 -0600
X-Mao-Original-Outgoing-Id: 440718320.500968-fbdf0943c954e95a68a21c4564ac6c88
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <79E0AA6A-8F91-45FD-AE8A-EFF9D2A4E9D3@nostrum.com> <5491AEC7.8070307@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7M111i30Xk9U3oPVWxtKKv8Q7To
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: Editorial Comments
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Dec 2014 21:45:25 -0000

> On Dec 17, 2014, at 10:26 AM, Steve Donovan  =
wrote:
>=20
>=20
> On 12/16/14, 9:02 PM, Ben Campbell wrote:
>>=20

[...]

>> We keep referring to the DOIC "solution". I think "mechanism" is more =
appropriate. I would think of a DOIC "solution" as a deployment that =
leverages the DOIC "mechanism".
> SRD> I don't see an issue here, as long as we are consistent.

I think we are pretty consistent in saying "solution". I guess that =
seems a bit pretentious to me, but I can live with it.

>>=20
>> We overuse the word Diameter in front of other things. E.g. Diameter =
nodes, Diameter Agents, Diameter clients, Diameter servers, etc. This =
entire draft is about Diameter; we don't have to keep saying it. It =
tends to get awkward when we use it a lot in close proximity.
> SRD> This was done based on feedback from Benoit.  We are being =
explicit.  If there are paragraphs where it is particularly cumbersome, =
please point out those paragraphs and we can try to make them less =
cumbersome.

I'd argue that explicit and redundant are not the same things. (The =
document is pretty explicit that we are talking Diameter.)  But if =
Benoit wants it, I won't complain further, other than to note that RFC =
6733 uses the terms client, agent, and server regularly without =
prefixing them with Diameter.  :-)

[...]

>>=20
>> -- section 2, Realm-Routed Requests: "... does not know the host that =
will service..."
>>=20
>> I suggest: "... does not know which host will service ..."
> SRD> Ok.
>>=20
>> We should also add a comment that it may be possible to apply =
diversion to realm routed requests.
> SRD> Where?

In the realm-routed request definition. (This was a continuation of the =
previous comment.)


>>=20
>> -- section 3, 2nd paragraph:
>>=20
>> Client, servers, and agents should not be capitalized. Should =
"Reporting node" and "Reacting node" be hyphenated?  Consider moving the =
last sentence to the start of the next paragraph.
> SRD> The capitalization of Diameter Clients, Diameter Servers and =
Diameter agents was Benoit's suggestion to make it explicit what is =
being referred to.

RFC 6733 does not generally capitalize client, agent, or server. I agree =
that Diameter is  a proper name, but the other terms are not.=20


>  I don't see the need for hyphenation in this context.

I don't have strong feelings on that one.

>  I'm ok with moving the sentence.
>>=20


>>=20
>> -- section 3.2, paragraph 11: "The DCA mechanism must also allow..."
> SRD> This paragraph looks redundant.  I suggest removing it.

Isn't this the first mention of the feature vector indicating things =
other than algorithms? If so, I'm not sure I agree that it's redundant.

>>=20
>> --> "The DCA mechanism allows..."
>>=20

>>=20
>> Much of this section is redundant to stuff in the parent section. I =
suggest reducing the parent section detail, and keeping it here. (This =
may be true for subsequent children of section 3.)
> SRD> Do you have specific suggestions?

Remove the 2nd to last and 3rd to last paragraph in 3.0.

>>=20
>> -- 3.3, third paragraph:
>>=20
>> s/ , / : /
> SRD> I don't agree.  The commas are there because it is a list.

A colon is the appropriate punctuation to set a list or enumeration off =
from the preceding text. This would be more obvious if the list included =
more than 2 items, so that it would have imbedded commas.  (e.g. "I have =
three things: The first thing, the second thing, and the third thing.")

>>=20
>> -- 3.3, paragraph 4:
>>=20
>> In this overview, I suggest text saying that HOST_REPORT indicates a =
host report, and just using the term "host report" the rest of the time. =
(Same for realm report)
> SRD> Why?

We currently aren't consistent. Sometimes we say "host report", and =
sometimes we say "report of type 'HOST_REPORT'". I suggest we make that =
consistent, and "host report" is the less cumbersome.

[...]

>>=20
>> -- 3.4, para 2: " ... the definition of new report types and the =
definition of new scopes ..."
>>=20
>> Aren't these sort of the same thing? That is, you add new scopes by =
extending report type?
> SRD> Can't you have a how report that applies only to sessions on that =
host?

By adding some new AVP that indicates sessions? I guess so.

>>=20
>> -- 3.4, para 3:
>>=20
>> First two sentences are a bit confusing. A new reader will likely =
think they contradict, without some explanation that OC-Feature-Vector =
is a child of OC-S-F.
> SRD> They seam clear to me.  Do you have a suggested clarification?

"A DOIC node communicates supported features by including them in the =
OC-Feature-Vector AVP, as a sub-AVP of OC-Supported-Features.

>>=20
>> -- 3.4, para 4:
>>=20
>> First sentence has already been stated more than once. No need to =
repeat here.
> SRD> The first sentence is there to provide context for the second =
sentence.

That can be done less redundantly. For example:

"Overload reports can be also extended by adding new sub-AVPs to the =
OC-OLR AVP, allowing ..."


>>=20
>> -- 4.1.2, para 2:
>>=20
>> It's probably worth reiterating that the reacting node may not be the =
server, and this requirement may mean inserting AVPS into answers that =
came from upstream.
> SRD> I don't see the need.  Do you have suggested wording?

Nevermind. I think 4.1.3 handles this.
>>=20
>> -- 4.1.2, para 7: "If it selects a different algorithm, it MUST...:
>>=20
>> This is also true if it needs to announce some other feature that =
needs to be indicated.
> SRD> This paragraph is talking specifically about algorithms and is =
needed because the AVP is optional.  Are you suggesting another =
sentence, another paragraph?  I'm guessing that the case you talk about =
is already covered elsewhere.

We say this in 4.1.1 on reacting node behavior. We should make the same =
statement for reporting node behavior. This is the definitive section on =
reporting node behavior. If it's repeated elsewhere, we should consider =
whether _that_ text is redundant.

>>=20
>> -- 4.1.3, para 3: "... Agent MUST include OC-Supported-Features in =
request messages it receives..."
>>=20
>> I suspect this should say "... requests that it _forwards_" or =
"_relays_".
> SRD> To differentiate between the requests that it rejects.

Or requests that it normally wouldn't relay. (e.g. watchdogs, =
capabilities exchange, etc.)

>  Ok, I think relays is the better word.

Ok.

>>=20
>> -- 4.1.3, para 5 and 6:
>>=20
>> Is the reporting node section limited to endpoints? If not, the these =
paragraphs effectively restate normative language about reporting node =
behavior from that section. Once we've said what a reporting node =
normatively has to do, we should just be able to say that an agent =
acting as a reporting node has all the responsibilities of a reporting =
node, and not restate the normative requirements.
> SRD> I'm ok with this but it feels like more than an editorial change =
to me.

I don't think it would change the meaning, just the structure. (I _did_ =
mention "structural" in the preface to my comments :-)  )


>>=20
>> -- 4.1.3, para 7:
>>=20
>> The first MAY is a consequence (the complement) of the 2nd MAY. It =
should at least not be 2119 language, and probably can be omitted =
entirely.
> SRD> Do you have suggested wording?

"If a request already has the OC-Supported-Features AVP, a Diameter =
agent MAY modify it to reflect the features appropriate for the =
transaction."

Any MAY has an an implied "MIGHT NOT". But if we think it's not clear, =
we can tack on "Otherwise, the agent relays the OC-Supported-Features =
AVP without change."

>>=20
>> -- 4.1.3, para 9, last sentence:
>>=20
>> Does this mean an agent can only change OC-S-F in an answer if it =
changed it in the request? I don't think we want that restriction, but =
the context and "as such," seem to scope the MAY to that situation.
> SRD> I don't read it that way.  The first sentence is describing one =
reason why an agent might change OC-S-F.  It doesn't say it is the only =
reason.

I read "as such" to make the second sentence dependent on the first. If =
we want to make them equal, I suggest removing the "as such".

>>=20
>> -- 4.1.3, para 9: "ambiguity"
>>=20
>> I'm not sure that's is the word we want here. An agent could muck =
things up without being ambiguous. Perhaps "inconsistency"?
> SRD> The point is that the reacting nodes and reporting nodes must =
unambiguously know what to do.  I think ambiguous is the right word.

I can construct behavior that is not ambiguous to upstream or downstream =
nodes, but still breaks normative requirements. How about " ... ensure =
that it does not introduce incorrect behavior for either the upstream or =
downstream DOIC nodes."

>>=20
>> -- 4.2.1.1, para 1:
>>=20
>> Do I understand correctly that the reacting node only keeps OCS for =
those combinations that it has actually received an OLR for? If so, =
that's not clear from the wording.
> SRD> Do you have suggested wording?

It depends. Does a reacting node keep OCS when it hasn't received an =
OLR?

If no:

"A reacting node SHOULD maintain the following OCS for each active OLR =
it receives per Diameter application..."

if yes:

Then I think the section needs some more thought to distinguish between =
what is stored for OLRs, vs when no OLR is received.

Also, I think the preface to the second bullet list seems wrong. I don't =
see how you could make an implementation work right without at least =
keeping sequence number and expiration time, at least when you have an =
active OLR.



>>=20
>> -- 4.2.1.2, para 1:
>>=20
>> Likewise, the reporting node only keeps OCS for actual overload =
conditions where it sends OLRs?
> SRD> Do you have suggested wording?
>>=20

This seems dependent on the same question as for the last comment. But =
assuming it only has to keep state of actual OLRs:

"A reporting node SHOULD maintain OCS entries for each OLR it sends, per =
..."

>> -- 4.2.1.3, para 2:
>>=20
>> Should this combination include origin-host or origin-realm? App-Id?
> SRD> I don't understand this.

Ah, I misread the paragraph. But I think we are really talking about the =
algorithm, OC-OLR AVP, and other AVPs in the answer that are needed to =
understand the OLR. (e.g. Origin-Host, Origin-Realm, Application)

[...]

>>=20
>> -- 4.2.1.3, 3rd para from end: "... update the OCS entry as being =
expired."
>>=20
>> I suggest language like " invalid" or "terminated". I take "expired" =
to mean "naturally expired", which is different from the case described =
here. There may be subtle behavior difference. (For example, a reacting =
node might choose to log "expirations" differently than "explicit =
terminations".)
> SRD> For the context of this specification I think expired works.  =
Implementations can differentiate types of expired if they have a =
reason.  Nothing here prevents that.

Ok.

[...]

>>=20
>> -- 4.2.2, 2nd to last para:
>>=20
>>  I think we need something a bit stronger here. The endpoint needs to =
take some action that makes sense for the application. The details of =
that are beyond our scope, but the general need is not.
> SRD> We cannot enforce application behavior in a Diameter =
specification.   I don't see the need for anything more .  Do you have =
suggested wording?

Diameter endpoints that throttle requests [ MUST /need to ] do so =
according to the rules of the client application. Those rules will vary =
by application, and are beyond the scope of this document.


>> -- 4.2.3, para 2:
>>=20
>> Doesn't this also need to match the scope for the request type? E.g. =
Destination realm or destination host? For example, a host report for =
host A would not match OCS for host B, even though both had the same =
report type and application id.
> SRD> I guess this matters when an agent is the reporting node.
>>=20

I think it matters the same if the reporting node is an endpoint. For =
example, would you consider a host-routed-request with D-H: "foo" to =
match an host report for host "bar"?  (I'm on the fence here whether =
that is correct behavior, but I think the behavior should be the same =
for endpoints and agents.)

Actually, on reflection, how does this affect the scenario of an agent =
that passes through a host report and generates a realm report? Or a =
server that generates both?

>> -- 4.2.3, last para:
>>=20
>> An example of what we have in mind could be helpful here.
> SRD> I'm open to suggested wording...
>>=20

Add "For example, it might wait some period of time after overload ends =
before terminating the OLR, or it might send a series of OLRs indicating =
progressively less overload severity."

>>=20
>> -- 4.3, para 4:
>>=20
>> We should clarify that this is talking about mandatory to understand =
for DOIC, but not for the enclosing transaction.
> SRD> i'm not clear on what you are suggesting.

We need to be clear that receiving a DOIC avp with a mandatory AVP that =
you don't understand means you ignore the DOIC AVPs, but does not cause =
the Diameter transaction to fail. Or was it your intent to allow an =
application to say that if you get a DOIC avp that you can't process, =
you have to fail the Diameter transaction?

>  Do you have suggested wording?

Depends on the answer to the question above.

[...]


>>=20
>> -- 5.1, para 4:
>>=20
>> Convoluted paragraph. How about "How about "reporting nodes request =
the stateless reduction of the number of requests by an indicated =
percentage."
> SRD> Ok.
>>=20
>> We should also clarify that this reduction is in comparison to what =
the reacting node otherwise would have sent, rather than what it may =
have previously sent.
> SRD> Isn't this already covered?  Do you have suggested wording?

I don't see where we say it in the definition of "loss". It's implied by =
the example logic, but I think it needs to be more explicit. How about =
adding the following sentence:

"This percentage reduction is in comparison to the number of messages =
the node otherwise would send, regardless of how many requests the node =
might have sent in the past."


>>=20
>> -- para 6, last paragraph
>>=20
>> Paragraph is off topic for section. It probably belongs in the =
extensibility section, or at least somewhere other than here.
> SRD> Do you mean section 6? This isn't about extensibility but about =
how Diameter applications integrate DOIC.

Agreed that it is probably not about extensibility. But it's not about =
AVP definitions, either.

>  It probably belongs in the intro or overview sections.

Agreed. I'd suggest the intro.



>>=20
>> -- 6.2:
>>=20
>> Why did the AVP code jump to TBD6? (Also seems out of order in the =
table.)
> SRD> Historical reasons.  Doesn't matter, the real values will be =
filled in eventually.
>>=20

IANA will probably allocate them in order of TBDX numbers. I'd suggest =
reordering them (here and in the table) to keep child AVP definitions =
with their parent definition.



From nobody Mon Dec 22 05:14:38 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506FB1A03A8 for ; Mon, 22 Dec 2014 05:14:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9yCBjNCu8_h for ; Mon, 22 Dec 2014 05:14:35 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 117151A8BC4 for ; Mon, 22 Dec 2014 05:14:32 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: dime@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.9.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141222131432.16903.66371.idtracker@ietfa.amsl.com>
Date: Mon, 22 Dec 2014 05:14:32 -0800
From: IETF Secretariat 
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-bhFSRl21Pyt5dQNPfC0XBfsyyw
Subject: [Dime] Milestones changed for dime WG
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Dec 2014 13:14:37 -0000

Changed milestone "Submit a document on 'Diameter Load Information' as
a working group item", set state to active from review, accepting new
milestone.

Changed milestone "Submit I-D 'Diameter Load Information' to the IESG
for consideration as a Proposed Standard", set state to active from
review, accepting new milestone.

URL: http://datatracker.ietf.org/wg/dime/charter/


From nobody Mon Dec 22 05:26:25 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AD61A03AB for ; Mon, 22 Dec 2014 05:26:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsp_Tq-Tzxc0 for ; Mon, 22 Dec 2014 05:26:22 -0800 (PST)
Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78D781A03A8 for ; Mon, 22 Dec 2014 05:26:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=802; q=dns/txt; s=iport; t=1419254781; x=1420464381; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=iefCchoR7xH8RDAMIUWbt4YHH/m1KGqkb1rzkw+cRqs=; b=TI9THbsMelJ7fx+s/AhUArSuCfaCj25qILKxtz9SSgLAGST+kbjNEXbG 8uAedQzQMu6d3nugAEdO4x58w+ZxdwQx0JNndc1GapdlDzsEc9yVzC+av 6iZQX4VtXdghp+NUS6WGv5xvUjtZFQdQs8uxn/XNlFDWTVhYxLUuX2ogv g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Au4EAAobmFRIo8UY/2dsb2JhbABbg1hYxj0KhXACgTABAQEBAX2EDQEBBAEBATU2ChELIQwKDwkDAgECARUwBgEMBgIBARCIGA3POAEBAQEBAQEBAQEBAQEBAQEBAQEBFASPeQqEHwEElwOGA4tIIoNvPTGCQwEBAQ
X-IronPort-AV: E=Sophos;i="5.07,624,1413244800"; d="scan'208";a="48674323"
Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 22 Dec 2014 13:26:16 +0000
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by bgl-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBMDQ773027086; Mon, 22 Dec 2014 13:26:14 GMT
Message-ID: <54981BEF.7040706@cisco.com>
Date: Mon, 22 Dec 2014 14:26:07 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Jouni , "dime@ietf.org list" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/cKC8366jK7UwxxJtC4ILF1rAhOc
Subject: Re: [Dime] early IANA assignments for DOIC
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Dec 2014 13:26:23 -0000

Dear all,

I see many comments on DOIC, part of the WG last call.
I propose to finalize the formal request as soon as the WGLC comments 
are taken into account.

Regards, Benoit
> Folks,
>
> During the last meeting we had discussion on early IANA assignment of AVP codes for the DOIC. The actual process for that is now BCPed in RFC7120. So far we have one request, which hardly meets the criteria of the "sufficient interest in the community". Are there others (Steve is noted in the Honolulu meeting minutes) who would like to see the IANA process started already ahead of time before the I-D leaves the WG or around that time?.
>
> - Jouni & Lionel
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Mon Dec 22 06:12:32 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4DA1A8F45 for ; Mon, 22 Dec 2014 06:12:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.779
X-Spam-Level: 
X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5IpJQHJhftE for ; Mon, 22 Dec 2014 06:12:29 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099751A883C for ; Mon, 22 Dec 2014 06:12:29 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64427 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y33ii-0000RA-Gz; Mon, 22 Dec 2014 06:12:26 -0800
Message-ID: <549826C8.1090809@usdonovans.com>
Date: Mon, 22 Dec 2014 08:12:24 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  Ben Campbell 
References: <5486FE71.70205@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235215@DEMUMBX014.nsn-intra.net> <54884137.4050209@usdonovans.com> <5AB8BAC5-3CBD-432E-9631-74DF40795844@nostrum.com> <5489A498.5070203@usdonovans.com>  <5489EFAF.8010702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152358E0@DEMUMBX014.nsn-intra.net> <549046D3.3090104@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235AB9@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815235AB9@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------090602050901080206090402"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/i0XVfbDNsODdaPktfxTx4oj4Z_Q
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #15
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Dec 2014 14:12:31 -0000

This is a multi-part message in MIME format.
--------------090602050901080206090402
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

I have added the following statements:

    When receiving an answer message with multiple OLRs and multiple of
    the OLRs are of the same supported report types, a reporting node
    SHOULD ignore the duplicated OLRs.

    A reacting node SHOULD ignore an OC-OLR with a OC-Report-Type AVP
    that contains an unrecognized value.

Regards,

Steve

On 12/17/14 2:49 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Yes please.
>
> -----Original Message-----
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> Sent: Tuesday, December 16, 2014 3:51 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
> Cc: dime@ietf.org
> Subject: Re: [Dime] Ulrich's suggested change #15
>
> I'll delete the paragraph.
>
> Do we need explicit statements for the two conditions below?
>
> Steve
>
>
> On 12/15/14, 11:56 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Steve, Ben,
>>
>> I'm fine with deleting the paragraph.
>> But for my clarification please confirm that ignoring the complete set of OLRs is allowed when one of these OLRs contains a report type that was not advertized, or two of the OLRs contain the same report type.
>>
>> Regards
>> Ulrich
>>
>>
>>
>> -----Original Message-----
>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
>> Sent: Thursday, December 11, 2014 8:26 PM
>> To: Ben Campbell
>> Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
>> Subject: Re: [Dime] Ulrich's suggested change #15
>>
>>
>> On 12/11/14, 12:51 PM, Ben Campbell wrote:
>>>> On Dec 11, 2014, at 8:05 AM, Steve Donovan  wrote:
>>>>
>>>> I thought this paragraph was covering unrecognized values for all AVPs.
>>> I agree that's what it covered. But I think we failed to cover the unrecognized AVP case. If we don't have anything to say beyond what 6733 says, then it might not be strictly necessary, but it might still be worth saying that "unrecognized sub-AVPs are treated as per RFC6733".
>> That is probably worth saying.
>>>>     Maybe it is better to remove the paragraph entirely and make sure that the definition of each AVP addresses what is done with unrecognized values.
>>> Possibly. There are AVPs where there's no such thing as an unrecognized value. There may be AVPs where the allowed values vary by algorithm. If we do take that route, we probably need language here that says unrecognized values are handled as described by the AVP definition or the algorithm.
>> Agreed.
>>>> Steve
>>>>
>>>> On 12/10/14, 5:26 PM, Ben Campbell wrote:
>>>>>> On Dec 10, 2014, at 6:48 AM, Steve Donovan  wrote:
>>>>>>
>>>>>> Ulrich,
>>>>>>
>>>>>> Actually, the wording you suggested wasn't quite right.  It should be:
>>>>>>
>>>>>>      When receiving an OC-OLR AVP with unknown values, the overload report
>>>>>>      SHOULD be silently discarded by reacting nodes and the event SHOULD
>>>>>>      be logged.
>>>>>>
>>>>>> It's not just about report type values but unknown values for any of the AVPs in the OLR.
>>>>>>
>>>>>> This seems like a good requirement to include in the specification to ensure common behavior in reacting nodes.  I don't feel strongly about this but I would like to hear other opinions.
>>>>> I think this is still not quite complete.
>>>>>
>>>>> If you receive a sub-AVP that you don't understand, then you should ignore that sub-avp, not the whole OC-OLR AVP.  (Unless of course the unknown AVP has the m-bit set.) If you receive a known sub-AVP, with a value you don't understand, the behavior should be AVP specific. For Report-Type, that means ignore the whole OLR.
>>>>>
>>>>> It's not clear to me whether the original text was about arbitrary avps, or Report-Type.
>>>>>
>>>>>> Steve
>>>>>>
>>>>>> On 12/9/14, 11:04 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>>>>> Hi Steve,
>>>>>>>
>>>>>>> I think it was pointed out by Ben that we do not specify behaviour of a node for cases where it detects that another node is breaking the rule.
>>>>>>> The rule is:
>>>>>>>       A reporting node MUST NOT send overload reports of a type that has
>>>>>>>       not been advertised as supported by the reacting node.
>>>>>>> See section 4.2.3.
>>>>>>>
>>>>>>> Regards
>>>>>>> Ulrich
>>>>>>>
>>>>>>>      From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>>>>>>> Sent: Tuesday, December 09, 2014 2:52 PM
>>>>>>> To: dime@ietf.org
>>>>>>> Subject: [Dime] Ulrich's suggested change #15
>>>>>>>
>>>>>>> Ulrich,
>>>>>>>
>>>>>>> For your suggested change #15:
>>>>>>> Section 4.2.1.3, 4th paragraph:
>>>>>>> Existing text:
>>>>>>>       When receiving an OC-OLR AVPs with unknown values, a reacting node
>>>>>>>       SHOULD be silently discarded by reacting nodes and the event SHOULD
>>>>>>>       be logged.
>>>>>>> Comment: text is confusing. Maybe the intention was to say:
>>>>>>>       When receiving an OC-OLR AVPs with an unsupported report type value, a reacting node
>>>>>>>       SHOULD silently discarded the OC-OLR AVP and the event SHOULD
>>>>>>>       be logged.
>>>>>>> But even that is not correct.
>>>>>>> Proposal: Remove the paragraph.
>>>>>>> The intent was that an OC-OLR that contains unknown values should be discarded.  I agree that the wording needs to be changes as you suggested.  I don't agree with removing the paragraph.  Can you elaborate on why you think it is not correct when changed as you suggested?
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>> _______________________________________________
>>>>>> DiME mailing list
>>>>>> DiME@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/dime
>


--------------090602050901080206090402
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    I have added the following statements:

    

    
    
   When receiving an answer message with multiple OLRs and multiple of
   the OLRs are of the same supported report types, a reporting node
   SHOULD ignore the duplicated OLRs.

   A reacting node SHOULD ignore an OC-OLR with a OC-Report-Type AVP
   that contains an unrecognized value.


    Regards,

    

    Steve

    

    
On 12/17/14 2:49 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
Yes please.

-----Original Message-----
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] 
Sent: Tuesday, December 16, 2014 3:51 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
Cc: dime@ietf.org
Subject: Re: [Dime] Ulrich's suggested change #15

I'll delete the paragraph.

Do we need explicit statements for the two conditions below?

Steve


On 12/15/14, 11:56 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:


      

        
Steve, Ben,

I'm fine with deleting the paragraph.
But for my clarification please confirm that ignoring the complete set of OLRs is allowed when one of these OLRs contains a report type that was not advertized, or two of the OLRs contain the same report type.

Regards
Ulrich



-----Original Message-----
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Thursday, December 11, 2014 8:26 PM
To: Ben Campbell
Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Ulrich's suggested change #15


On 12/11/14, 12:51 PM, Ben Campbell wrote:


        

          

            
On Dec 11, 2014, at 8:05 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

I thought this paragraph was covering unrecognized values for all AVPs.


          

          
I agree that's what it covered. But I think we failed to cover the unrecognized AVP case. If we don't have anything to say beyond what 6733 says, then it might not be strictly necessary, but it might still be worth saying that "unrecognized sub-AVPs are treated as per RFC6733".


        

        
That is probably worth saying.


        

          

            
   Maybe it is better to remove the paragraph entirely and make sure that the definition of each AVP addresses what is done with unrecognized values.


          

          
Possibly. There are AVPs where there's no such thing as an unrecognized value. There may be AVPs where the allowed values vary by algorithm. If we do take that route, we probably need language here that says unrecognized values are handled as described by the AVP definition or the algorithm.


        

        
Agreed.


        

          

            
Steve

On 12/10/14, 5:26 PM, Ben Campbell wrote:


            

              

                
On Dec 10, 2014, at 6:48 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

Ulrich,

Actually, the wording you suggested wasn't quite right.  It should be:

    When receiving an OC-OLR AVP with unknown values, the overload report
    SHOULD be silently discarded by reacting nodes and the event SHOULD
    be logged.

It's not just about report type values but unknown values for any of the AVPs in the OLR.

This seems like a good requirement to include in the specification to ensure common behavior in reacting nodes.  I don't feel strongly about this but I would like to hear other opinions.


              

              
I think this is still not quite complete.

If you receive a sub-AVP that you don't understand, then you should ignore that sub-avp, not the whole OC-OLR AVP.  (Unless of course the unknown AVP has the m-bit set.) If you receive a known sub-AVP, with a value you don't understand, the behavior should be AVP specific. For Report-Type, that means ignore the whole OLR.

It's not clear to me whether the original text was about arbitrary avps, or Report-Type.



              

                
Steve

On 12/9/14, 11:04 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:


                

                  
Hi Steve,

I think it was pointed out by Ben that we do not specify behaviour of a node for cases where it detects that another node is breaking the rule.
The rule is:
     A reporting node MUST NOT send overload reports of a type that has
     not been advertised as supported by the reacting node.
See section 4.2.3.

Regards
Ulrich

    From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 09, 2014 2:52 PM
To: dime@ietf.org
Subject: [Dime] Ulrich's suggested change #15

Ulrich,

For your suggested change #15:
Section 4.2.1.3, 4th paragraph:
Existing text:
     When receiving an OC-OLR AVPs with unknown values, a reacting node
     SHOULD be silently discarded by reacting nodes and the event SHOULD
     be logged.
Comment: text is confusing. Maybe the intention was to say:
     When receiving an OC-OLR AVPs with an unsupported report type value, a reacting node
     SHOULD silently discarded the OC-OLR AVP and the event SHOULD
     be logged.
But even that is not correct.
Proposal: Remove the paragraph.
The intent was that an OC-OLR that contains unknown values should be discarded.  I agree that the wording needs to be changes as you suggested.  I don't agree with removing the paragraph.  Can you elaborate on why you think it is not correct when changed as you suggested?

Regards,

Steve



                

                
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


              

            

          

        

        

      

      



    

    

  


--------------090602050901080206090402--


From nobody Mon Dec 22 06:30:06 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816E41A8FD2 for ; Mon, 22 Dec 2014 06:30:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.279
X-Spam-Level: 
X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puVxaZrdXq-j for ; Mon, 22 Dec 2014 06:30:02 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C203B1A8F4D for ; Mon, 22 Dec 2014 06:30:02 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64440 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y33zg-000871-JX; Mon, 22 Dec 2014 06:30:00 -0800
Message-ID: <54982AE4.2070705@usdonovans.com>
Date: Mon, 22 Dec 2014 08:29:56 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  ext Ben Campbell 
References: <548701E1.3060502@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235234@DEMUMBX014.nsn-intra.net> <54884556.90108@usdonovans.com> <9B6C0FB1-B3D5-4050-B79D-E429A440CE79@nostrum.com> <5489F246.5040801@usdonovans.com> <8D4FC2F7-30F8-41AF-9F19-209BB48FCB9D@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668152359A7@DEMUMBX014.nsn-intra.net> <549047A0.4060503@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235BEF@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815235BEF@DEMUMBX014.nsn-intra.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/oEuh3_F-nvnd0F36grhnpIiToSI
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #16
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Dec 2014 14:30:04 -0000

I've made this change.  It will be in the next version of -06 that 
should come out today.

Steve

On 12/18/14 3:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
>
> I'm still not convinced.
>
> Another proposal:
>
> If diversion abatement treatment is possible (i.e. a different path for the request can be selected where the overloaded node is not part of the different path), then the reacting node SHOULD apply diversion abatement treatment to the request. Otherwise the reacting node SHOULD apply throttling abatement treatment to the request.
>
> Ulrich
>
> -----Original Message-----
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> Sent: Tuesday, December 16, 2014 3:54 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
> Cc: dime@ietf.org
> Subject: Re: [Dime] Ulrich's suggested change #16
>
> Ulrich,
>
> I still think the following statements are sufficient:
>
>      For OLRs of type host, if the request is a host-routed request then the reacting node SHOULD
>      apply throttling abatement treatment to the request.
>
>      For OLRs of type host, if the request is a realm-routed request then the reacting node
>      SHOULD apply diversion abatement treatment to the request.
>
>      For OLRs of type realm, the reacting node SHOULD
>      apply throttling abatement treatment to the request, independent of the type (host-routed or
>      realm-routed) of request.
>
> Regards,
>
> Steve
>
> On 12/15/14, 2:42 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Steve,
>> can you please summarize the status of #16. I'm getting lost.
>>
>> Regards
>> Ulrich
>>
>> -----Original Message-----
>> From: ext Ben Campbell [mailto:ben@nostrum.com]
>> Sent: Thursday, December 11, 2014 8:45 PM
>> To: Steve Donovan
>> Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
>> Subject: Re: [Dime] Ulrich's suggested change #16
>>
>>
>>> On Dec 11, 2014, at 1:36 PM, Steve Donovan  wrote:
>>>
>>>
>>> On 12/11/14, 1:03 PM, Ben Campbell wrote:
>>>>> On Dec 10, 2014, at 7:06 AM, Steve Donovan  wrote:
>>>>>
>>>>> Ulrich,
>>>>>
>>>>> I agree with your assumptions below.  For the third one, the only time it is possible, at least from a DOIC perspective, to send to another host is if it is a realm-routed request.  I might also change the "not overloaded" to "less overloaded".
>>>>>
>>>>> I do think the statements can be improved to differentiate between behavior for host reports and realm reports.
>>>>>
>>>>> How about the following:
>>>>>      For OLRs of type host, if the request is a host-routed request then the reacting node SHOULD
>>>>>      apply throttling abatement treatment to the request.
>>>>>
>>>>>      For OLRs of type host, If the request is a realm-routed request then the reacting node
>>>>>      SHOULD apply diversion abatement treatment to the request.
>>>> Personally, I think that should be non-normative. Or if normative, no stronger than MAY. I agree it's a good choice, but I think we can leave it to the market to enforce.
>>> If we make it non normative then we probably need an additional statement along the lines of "the reacting node MUST attempt to reduce traffic by the amount requested in the OLR" if we don't already have it somewhere else in the document.
>> Agreed
>>
>>>> I think there when we distinguish request-type, we need to consider _when_. For example, an agent may _receive_ a realm routed request but _send_ a host-routed request. And for a client, that may be even more subtle.
>>>>
>>>> This really does seem like a case of server selection.
>>> I don't think it's that subtle.  If server selection hasn't already happened for a request and that request is selected for abatement and the request would have otherwise been routed to an overloaded host then the request should/may be diverted to another server.
>>>
>>> Server selection could have happened as a result of a previous transaction specifying the host for subsequent transactions or by the presence of the Destination-Host in the message when it arrives at an agent.  It could have also already happened as a result of configuration.
>> In the case of a client, the decision on whether to divert vs just not send a request may be heavily influenced by the client application.  (Not necessarily the _Diameter_ application.)  In the case of either, a node might have local knowledge that a 2nd server can handle everything the first server can handle. Even if a downstream node performed server selection, a node with such knowledge might override it. We don't necessarily need to talk about that sort of thing, but we should avoid language that forbids it.
>>
>>
>>>>>      For OLRs of type realm, the reacting node SHOULD
>>>>>      apply throttling abatement treatment to the request, independent of the type (host-routed or
>>>>>      realm-routed) of request.
>>>> Again, I think this should not be normative. In this case this is pretty much a statement of fact--you simply cannot reasonably divert given the way that Diameter routing works. I suppose there might be a case where a node has some magical knowledge that realm2 can handle anything that realm1 can, and could divert to a different realm (which we probably still don't want to forbid.)
>>>>
>>>>> Regards,
>>>>>
>>>>> Steve
>>>>>
>>>>> On 12/9/14, 11:29 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>>>> Steve,
>>>>>> yes, then, maybe, the definition of Diversion is not correct?
>>>>>> What are other people's views?
>>>>>>
>>>>>> My assumption was:
>>>>>> If a host is overloaded, it does not help to direct traffic to that host via a different path.
>>>>>> If a realm is overloaded, it does not help to direct traffic to that realm via a different path.
>>>>>> If a host is overloaded, it helps to select an alternative (not overloaded) host (if possible) and direct traffic to that host.
>>>>>> If a realm is overloaded, there never is an alternative (not overloaded) realm to which traffic could be directed.
>>>>>>
>>>>>> With the current definition of Diversion, Diversion is no appropriate means to address host overload and is no appropriate means to address realm overload. It may be ok for agent overload only.
>>>>>>
>>>>>> Regards
>>>>>> Ulrich
>>>>>>
>>>>>> From: DiME [
>>>>>> mailto:dime-bounces@ietf.org
>>>>>> ] On Behalf Of ext Steve Donovan
>>>>>> Sent: Tuesday, December 09, 2014 3:06 PM
>>>>>> To:
>>>>>> dime@ietf.org
>>>>>>
>>>>>> Subject: [Dime] Ulrich's suggested change #16
>>>>>>
>>>>>> Ulrich,
>>>>>>
>>>>>> For your suggested change #16:
>>>>>> Section 4.2.2, 5th and 6th paragraph:
>>>>>> Existing text:
>>>>>>      If the request is a host-routed request then the reacting node SHOULD
>>>>>>      apply throttling abatement treatment to the request.
>>>>>>        If the request is a realm-routed request then the reacting node
>>>>>>      SHOULD apply diversion abatement treatment to the request.
>>>>>>
>>>>>> Comment: I don't think so. If the reacting node selects the server and
>>>>>> then detects that the selected server is overloaded and then detects that
>>>>>> the request does not survive (i.e. is subject to abatement), then the reacting
>>>>>> node SHOULD apply diversion treatment (i.e. select an alternative server if possible).
>>>>>> If the reacting node does not select the server (either a. because the server was
>>>>>> already selected by a downstream node, or b. because the server will be selected
>>>>>> by an upstream node) then there is no point in applying diversion and the reacting
>>>>>> node SHOULD apply throttling of requests that do not survive.
>>>>>>
>>>>>> Proposal: replace the paragraphs with:
>>>>>>      If the reacting node does not select the server then it SHOULD apply
>>>>>>      throttling abatement to the request.
>>>>>>
>>>>>>      If the reacting node selects the server then it SHOULD apply diversion
>>>>>>      abatement treatment (i.e. select an alternative server if possible) to
>>>>>>      the request.
>>>>>> Diversion is not selecting an alternative node to handle the request.  Diversion is selecting an alternative route to the selected node.
>>>>>>
>>>>>> Whether it is appropriate to select an alternative node for a request is an application decision that probably changes on a per command-code basis within the application. Logic like this is outside the scope of the DOIC specification.
>>>>>>
>>>>>> The text is correct based on the definition of diversion.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Mon Dec 22 06:33:25 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDB01A8FD4 for ; Mon, 22 Dec 2014 06:33:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.279
X-Spam-Level: 
X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tgARC0mXrs7 for ; Mon, 22 Dec 2014 06:33:17 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FB111A8FD5 for ; Mon, 22 Dec 2014 06:33:17 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64443 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y342q-000C97-6K; Mon, 22 Dec 2014 06:33:16 -0800
Message-ID: <54982BA7.70005@usdonovans.com>
Date: Mon, 22 Dec 2014 08:33:11 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  Ben Campbell 
References: <5486FCBF.4000707@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152351D9@DEMUMBX014.nsn-intra.net> <54883F5C.1060603@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235675@DEMUMBX014.nsn-intra.net> <5489A416.2000403@usdonovans.com> <64AB1BC6-8D34-4DEB-B801-C5C127047C8C@nostrum.com> <54904C5A.2070502@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235C03@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815235C03@DEMUMBX014.nsn-intra.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/YdmksDRHhRHoSu7j4TygW9IfJ2E
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change @12
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Dec 2014 14:33:19 -0000

Number 3 is badly phrased.  It was supposed to be from the reporting 
node perspective.

Either way, I believe this issue is addressed by Ben's proposal in the 
DOIC WGLC: Changing Algorithms thread.

Regards,

Steve

On 12/18/14 3:17 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve, Ben,
>
> I'm in favour of 2).
> Actually I do not understand 3) as it talks about overload reports, while the issue is about capability anouncement.
>
> Ulrich
>
> -----Original Message-----
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> Sent: Tuesday, December 16, 2014 4:15 PM
> To: Ben Campbell
> Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] Ulrich's suggested change @12
>
> Ben,
>
> I see a two or three options here:
>
> 1) We add a new attribution AVP and all of the text associated with it.
> This has obvious schedule implications.
>
> 2) We treat this the same way as we treated the issue with multiple
> sources of OC-OLR AVPs and add text somewhere in the draft saying that
> if agents are selecting abatement algorithms then care must be taken to
> make sure that all agents that handle traffic for the same Diameter node
> must select the same algorithm for all transactions involving that
> Diameter node.
>
> 3) Number two plus reacting node behavior statements saying that the
> reacting node SHOULD ignore overload reports for a node that has an
> active OCS if the received overload report is of a different type then
> stored in the active OCS.
>
> I vote for number 3.
>
> Regards,
>
> Steve
>
> On 12/11/14, 12:38 PM, Ben Campbell wrote:
>>> On Dec 11, 2014, at 8:03 AM, Steve Donovan  wrote:
>>>
>>> Ulrich,
>>>
>>> I see your concern.  To summarize, if we have the following configuration:
>>>
>>>      ----A1----
>>>     /          \
>>>    C            S
>>>     \          /
>>>      ----A2----
>>>
>>> And A1 indicates loss in in the OC-S-F AVP in answer messages and A2 indicates rate then there is ambiguity.
>>>
>>> I agree, this warrants a warning statement somewhere in the document.
>>>
>>> If there is general agreement on this then I'll propose wording and location.
>>>
>> What sort of guidance should we give here? IMO, this is a worse problem than for realm reports, or at least having it for both realm and host reports makes it considerably worse than before. I think variations on this will happen for almost any Diameter network of non-trivial size.
>>
>> I also think it's reasonable that A1 and A2 might select different algorithms towards C. For example, lets say C, A1, and S all support rate, but A2 does not. S might select rate towards A1, but loss towards A2.
>>
>> If we can't handle this, I think the entire solution breaks down.
>>
>> I propose that the best way to handle this is to add source-attribution into OLRs, and guidance for what C should do if it gets different capabilities for the same host or realm from different paths. This _might_ also help solve the "different reports for same realm" problem and the "can't tell if an intervening agent supports DOIC" problem.
>>
>>
>>> Steve
>>>
>>> On 12/11/14, 7:31 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>> Steve,
>>>>    
>>>> yes, it's about capability announcement, and my concern in with announcing the selected algorithm in answer messages (while no OLRs are sent). Multiple  agents modifying the selected algorithm in the Supported-Features AVPs in answer messages may  result in ambiguity in DOIC behaviour for downstream DOIC nodes.
>>>>    
>>>> Ulrich
>>>>    
>>>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
>>>> Sent: Wednesday, December 10, 2014 1:41 PM
>>>> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
>>>> Subject: Re: [Dime] Ulrich's suggested change @12
>>>>    
>>>> Ulrich,
>>>>
>>>> This paragraph is talking about capability announcement.  We deal with the issues related to multiple sources of overload reports already elsewhere in the document.
>>>>
>>>> I still do see the need for a change.
>>>>
>>>> Steve
>>>>
>>>> On 12/9/14, 10:46 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>>> Steve,
>>>> I agree, my comment and proposal do not hit the mark.
>>>>    
>>>> The intention was to say that known issues exist if there are multiple agents on multiple paths between client and server. The agents may not be able to ensure that there is no ambiguity in DOIC behaviour for the client. E.g. from the client's point of view the answer to a first request (which was modified by agent A1) could indicate: DOIC is supported, currenty no overload, once in overload loss will be selected; and the answer to the next request (which was modified by agent A2) could indicate: DOIC is supported, some?? reduction is requested using rate. The client, however, may not be prepared for rate.
>>>>    
>>>> Maybe a warning note could be added to say that the agent may not always be able to ensure that there is no ambiguity.
>>>>    
>>>> Ulrich
>>>>    
>>>>    
>>>>    
>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>>>> Sent: Tuesday, December 09, 2014 2:45 PM
>>>> To: dime@ietf.org
>>>> Subject: [Dime] Ulrich's suggested change @12
>>>>    
>>>> Ulrich,
>>>>
>>>> For your suggested change #12:
>>>>
>>>> Section 4.1.3, last paragraph:
>>>> Existing text:
>>>>      When making changes to the OC-Supported-Features AVP the Diameter
>>>>      Agent needs to ensure that there is no ambiguity in DOIC behavior for
>>>>      both upstream and downstream DOIC nodes.
>>>>    
>>>> Comment: while that is true, in addition problems similar to those
>>>> identified in the note in section 3.3 may result from making changes.
>>>>    
>>>> Proposal: Add the note:
>>>>         Note: Known issues exist if multiple sources for overload reports
>>>>         which apply to the same Diameter entity exist.  Reacting nodes
>>>>         have no way of determining the source and, as such, will treat
>>>>         them as coming from a single source.  Variance in sequence numbers
>>>>         between the two sources can then cause incorrect overload
>>>>         abatement treatment to be applied for indeterminate periods of
>>>>         time.
>>>> I don't understand how these are related.  The change to the OC-Supported-Features AVP made by the agent apply only to the transaction.  In addition, this paragraph doesn't mention overload reports.
>>>>
>>>> Regards,
>>>>
>>>> Steve
>>>>
>>>>
>>>>
>>>>    
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Mon Dec 22 08:56:26 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7CE1A1A8C for ; Mon, 22 Dec 2014 08:56:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.579
X-Spam-Level: *
X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWFOAf-KqyBR for ; Mon, 22 Dec 2014 08:56:21 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E68C11A0371 for ; Mon, 22 Dec 2014 08:56:21 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64574 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y36HJ-0004mW-H9; Mon, 22 Dec 2014 08:56:20 -0800
Message-ID: <54984D31.5000201@usdonovans.com>
Date: Mon, 22 Dec 2014 10:56:17 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Ben Campbell 
References: <79E0AA6A-8F91-45FD-AE8A-EFF9D2A4E9D3@nostrum.com> <5491AEC7.8070307@usdonovans.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ZORgTupyiKARSx2Jxpja1u-BTcE
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: Editorial Comments
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Dec 2014 16:56:24 -0000

On 12/19/14 3:45 PM, Ben Campbell wrote:
>> On Dec 17, 2014, at 10:26 AM, Steve Donovan  wrote:
>>
>>
>> On 12/16/14, 9:02 PM, Ben Campbell wrote:
> [...]
>
>>> We keep referring to the DOIC "solution". I think "mechanism" is more appropriate. I would think of a DOIC "solution" as a deployment that leverages the DOIC "mechanism".
>> SRD> I don't see an issue here, as long as we are consistent.
> I think we are pretty consistent in saying "solution". I guess that seems a bit pretentious to me, but I can live with it.
>
>>> We overuse the word Diameter in front of other things. E.g. Diameter nodes, Diameter Agents, Diameter clients, Diameter servers, etc. This entire draft is about Diameter; we don't have to keep saying it. It tends to get awkward when we use it a lot in close proximity.
>> SRD> This was done based on feedback from Benoit.  We are being explicit.  If there are paragraphs where it is particularly cumbersome, please point out those paragraphs and we can try to make them less cumbersome.
> I'd argue that explicit and redundant are not the same things. (The document is pretty explicit that we are talking Diameter.)  But if Benoit wants it, I won't complain further, other than to note that RFC 6733 uses the terms client, agent, and server regularly without prefixing them with Diameter.  :-)
>
> [...]
>
>>> -- section 2, Realm-Routed Requests: "... does not know the host that will service..."
>>>
>>> I suggest: "... does not know which host will service ..."
>> SRD> Ok.
>>> We should also add a comment that it may be possible to apply diversion to realm routed requests.
>> SRD> Where?
> In the realm-routed request definition. (This was a continuation of the previous comment.)
SRD> I don't see the need.
>
>
>>> -- section 3, 2nd paragraph:
>>>
>>> Client, servers, and agents should not be capitalized. Should "Reporting node" and "Reacting node" be hyphenated?  Consider moving the last sentence to the start of the next paragraph.
>> SRD> The capitalization of Diameter Clients, Diameter Servers and Diameter agents was Benoit's suggestion to make it explicit what is being referred to.
> RFC 6733 does not generally capitalize client, agent, or server. I agree that Diameter is  a proper name, but the other terms are not.
>
>
>>   I don't see the need for hyphenation in this context.
> I don't have strong feelings on that one.
>
>>   I'm ok with moving the sentence.
>
>>> -- section 3.2, paragraph 11: "The DCA mechanism must also allow..."
>> SRD> This paragraph looks redundant.  I suggest removing it.
> Isn't this the first mention of the feature vector indicating things other than algorithms? If so, I'm not sure I agree that it's redundant.
SRD> I moved the paragraph.
>
>>> --> "The DCA mechanism allows..."
>>>
>>> Much of this section is redundant to stuff in the parent section. I suggest reducing the parent section detail, and keeping it here. (This may be true for subsequent children of section 3.)
>> SRD> Do you have specific suggestions?
> Remove the 2nd to last and 3rd to last paragraph in 3.0.
SRD> Done
>
>>> -- 3.3, third paragraph:
>>>
>>> s/ , / : /
>> SRD> I don't agree.  The commas are there because it is a list.
> A colon is the appropriate punctuation to set a list or enumeration off from the preceding text. This would be more obvious if the list included more than 2 items, so that it would have imbedded commas.  (e.g. "I have three things: The first thing, the second thing, and the third thing.")
SRD> I was looking at the wrong paragraph.  I agree with this change.
>
>>> -- 3.3, paragraph 4:
>>>
>>> In this overview, I suggest text saying that HOST_REPORT indicates a host report, and just using the term "host report" the rest of the time. (Same for realm report)
>> SRD> Why?
> We currently aren't consistent. Sometimes we say "host report", and sometimes we say "report of type 'HOST_REPORT'". I suggest we make that consistent, and "host report" is the less cumbersome.
SRD> I still don't see the need.
>
> [...]
>
>>> -- 3.4, para 2: " ... the definition of new report types and the definition of new scopes ..."
>>>
>>> Aren't these sort of the same thing? That is, you add new scopes by extending report type?
>> SRD> Can't you have a how report that applies only to sessions on that host?
> By adding some new AVP that indicates sessions? I guess so.
>
>>> -- 3.4, para 3:
>>>
>>> First two sentences are a bit confusing. A new reader will likely think they contradict, without some explanation that OC-Feature-Vector is a child of OC-S-F.
>> SRD> They seam clear to me.  Do you have a suggested clarification?
> "A DOIC node communicates supported features by including them in the OC-Feature-Vector AVP, as a sub-AVP of OC-Supported-Features.
SRD> Ok.
>
>>> -- 3.4, para 4:
>>>
>>> First sentence has already been stated more than once. No need to repeat here.
>> SRD> The first sentence is there to provide context for the second sentence.
> That can be done less redundantly. For example:
>
> "Overload reports can be also extended by adding new sub-AVPs to the OC-OLR AVP, allowing ..."
SRD> Ok.
>
>
>>> -- 4.1.2, para 2:
>>>
>>> It's probably worth reiterating that the reacting node may not be the server, and this requirement may mean inserting AVPS into answers that came from upstream.
>> SRD> I don't see the need.  Do you have suggested wording?
> Nevermind. I think 4.1.3 handles this.
>>> -- 4.1.2, para 7: "If it selects a different algorithm, it MUST...:
>>>
>>> This is also true if it needs to announce some other feature that needs to be indicated.
>> SRD> This paragraph is talking specifically about algorithms and is needed because the AVP is optional.  Are you suggesting another sentence, another paragraph?  I'm guessing that the case you talk about is already covered elsewhere.
> We say this in 4.1.1 on reacting node behavior. We should make the same statement for reporting node behavior. This is the definitive section on reporting node behavior. If it's repeated elsewhere, we should consider whether _that_ text is redundant.
SRD> Again, this paragraph is dealing specifically with rules around 
which the algorithms supported by the reporting node interact with the 
OC-Features-Vector AVP.  The statement on other features is three 
paragraphs later.
>
>>> -- 4.1.3, para 3: "... Agent MUST include OC-Supported-Features in request messages it receives..."
>>>
>>> I suspect this should say "... requests that it _forwards_" or "_relays_".
>> SRD> To differentiate between the requests that it rejects.
> Or requests that it normally wouldn't relay. (e.g. watchdogs, capabilities exchange, etc.)
>
>>   Ok, I think relays is the better word.
> Ok.
>
>>> -- 4.1.3, para 5 and 6:
>>>
>>> Is the reporting node section limited to endpoints? If not, the these paragraphs effectively restate normative language about reporting node behavior from that section. Once we've said what a reporting node normatively has to do, we should just be able to say that an agent acting as a reporting node has all the responsibilities of a reporting node, and not restate the normative requirements.
>> SRD> I'm ok with this but it feels like more than an editorial change to me.
> I don't think it would change the meaning, just the structure. (I _did_ mention "structural" in the preface to my comments :-)  )
SRD> I have removed the two offending paragraphs.
>
>
>>> -- 4.1.3, para 7:
>>>
>>> The first MAY is a consequence (the complement) of the 2nd MAY. It should at least not be 2119 language, and probably can be omitted entirely.
>> SRD> Do you have suggested wording?
> "If a request already has the OC-Supported-Features AVP, a Diameter agent MAY modify it to reflect the features appropriate for the transaction."
>
> Any MAY has an an implied "MIGHT NOT". But if we think it's not clear, we can tack on "Otherwise, the agent relays the OC-Supported-Features AVP without change."
SRD> Changed, including the Otherwise... sentence.
>
>>> -- 4.1.3, para 9, last sentence:
>>>
>>> Does this mean an agent can only change OC-S-F in an answer if it changed it in the request? I don't think we want that restriction, but the context and "as such," seem to scope the MAY to that situation.
>> SRD> I don't read it that way.  The first sentence is describing one reason why an agent might change OC-S-F.  It doesn't say it is the only reason.
> I read "as such" to make the second sentence dependent on the first. If we want to make them equal, I suggest removing the "as such".
SRD> Ok.
>
>>> -- 4.1.3, para 9: "ambiguity"
>>>
>>> I'm not sure that's is the word we want here. An agent could muck things up without being ambiguous. Perhaps "inconsistency"?
>> SRD> The point is that the reacting nodes and reporting nodes must unambiguously know what to do.  I think ambiguous is the right word.
> I can construct behavior that is not ambiguous to upstream or downstream nodes, but still breaks normative requirements. How about " ... ensure that it does not introduce incorrect behavior for either the upstream or downstream DOIC nodes."
SRD> Ok.
>
>>> -- 4.2.1.1, para 1:
>>>
>>> Do I understand correctly that the reacting node only keeps OCS for those combinations that it has actually received an OLR for? If so, that's not clear from the wording.
>> SRD> Do you have suggested wording?
> It depends. Does a reacting node keep OCS when it hasn't received an OLR?
>
> If no:
>
> "A reacting node SHOULD maintain the following OCS for each active OLR it receives per Diameter application..."
>
> if yes:
>
> Then I think the section needs some more thought to distinguish between what is stored for OLRs, vs when no OLR is received.
>
> Also, I think the preface to the second bullet list seems wrong. I don't see how you could make an implementation work right without at least keeping sequence number and expiration time, at least when you have an active OLR.
>
>
>
>>> -- 4.2.1.2, para 1:
>>>
>>> Likewise, the reporting node only keeps OCS for actual overload conditions where it sends OLRs?
>> SRD> Do you have suggested wording?
> This seems dependent on the same question as for the last comment. But assuming it only has to keep state of actual OLRs:
>
> "A reporting node SHOULD maintain OCS entries for each OLR it sends, per ..."
SRD> I'll start a thread to discuss these two items.
>
>>> -- 4.2.1.3, para 2:
>>>
>>> Should this combination include origin-host or origin-realm? App-Id?
>> SRD> I don't understand this.
> Ah, I misread the paragraph. But I think we are really talking about the algorithm, OC-OLR AVP, and other AVPs in the answer that are needed to understand the OLR. (e.g. Origin-Host, Origin-Realm, Application)
>
> [...]
>
>>> -- 4.2.1.3, 3rd para from end: "... update the OCS entry as being expired."
>>>
>>> I suggest language like " invalid" or "terminated". I take "expired" to mean "naturally expired", which is different from the case described here. There may be subtle behavior difference. (For example, a reacting node might choose to log "expirations" differently than "explicit terminations".)
>> SRD> For the context of this specification I think expired works.  Implementations can differentiate types of expired if they have a reason.  Nothing here prevents that.
> Ok.
>
> [...]
>
>>> -- 4.2.2, 2nd to last para:
>>>
>>>   I think we need something a bit stronger here. The endpoint needs to take some action that makes sense for the application. The details of that are beyond our scope, but the general need is not.
>> SRD> We cannot enforce application behavior in a Diameter specification.   I don't see the need for anything more .  Do you have suggested wording?
> Diameter endpoints that throttle requests [ MUST /need to ] do so according to the rules of the client application. Those rules will vary by application, and are beyond the scope of this document.
SRD> Ok, without the MUST.
>
>
>>> -- 4.2.3, para 2:
>>>
>>> Doesn't this also need to match the scope for the request type? E.g. Destination realm or destination host? For example, a host report for host A would not match OCS for host B, even though both had the same report type and application id.
>> SRD> I guess this matters when an agent is the reporting node.
> I think it matters the same if the reporting node is an endpoint. For example, would you consider a host-routed-request with D-H: "foo" to match an host report for host "bar"?  (I'm on the fence here whether that is correct behavior, but I think the behavior should be the same for endpoints and agents.)
>
> Actually, on reflection, how does this affect the scenario of an agent that passes through a host report and generates a realm report? Or a server that generates both?
SRD> Yes, I believe it does.  I suggest we delete paragraph 2, as the 
criteria for matching an OCS will be report type dependent.
>
>>> -- 4.2.3, last para:
>>>
>>> An example of what we have in mind could be helpful here.
>> SRD> I'm open to suggested wording...
> Add "For example, it might wait some period of time after overload ends before terminating the OLR, or it might send a series of OLRs indicating progressively less overload severity."
SRD> Ok.
>
>>> -- 4.3, para 4:
>>>
>>> We should clarify that this is talking about mandatory to understand for DOIC, but not for the enclosing transaction.
>> SRD> i'm not clear on what you are suggesting.
> We need to be clear that receiving a DOIC avp with a mandatory AVP that you don't understand means you ignore the DOIC AVPs, but does not cause the Diameter transaction to fail. Or was it your intent to allow an application to say that if you get a DOIC avp that you can't process, you have to fail the Diameter transaction?
>
>>   Do you have suggested wording?
> Depends on the answer to the question above.
>
> [...]
SRD> This requires discussion on the list.  I'll start a thread.
>
>
>>> -- 5.1, para 4:
>>>
>>> Convoluted paragraph. How about "How about "reporting nodes request the stateless reduction of the number of requests by an indicated percentage."
>> SRD> Ok.
>>> We should also clarify that this reduction is in comparison to what the reacting node otherwise would have sent, rather than what it may have previously sent.
>> SRD> Isn't this already covered?  Do you have suggested wording?
> I don't see where we say it in the definition of "loss". It's implied by the example logic, but I think it needs to be more explicit. How about adding the following sentence:
>
> "This percentage reduction is in comparison to the number of messages the node otherwise would send, regardless of how many requests the node might have sent in the past."
SRD> Ok.
>
>
>>> -- para 6, last paragraph
>>>
>>> Paragraph is off topic for section. It probably belongs in the extensibility section, or at least somewhere other than here.
>> SRD> Do you mean section 6? This isn't about extensibility but about how Diameter applications integrate DOIC.
> Agreed that it is probably not about extensibility. But it's not about AVP definitions, either.
>
>>   It probably belongs in the intro or overview sections.
> Agreed. I'd suggest the intro.
SRD> Done.
>
>
>
>>> -- 6.2:
>>>
>>> Why did the AVP code jump to TBD6? (Also seems out of order in the table.)
>> SRD> Historical reasons.  Doesn't matter, the real values will be filled in eventually.
> IANA will probably allocate them in order of TBDX numbers. I'd suggest reordering them (here and in the table) to keep child AVP definitions with their parent definition.
SRD> Done.
>
>
>


From nobody Mon Dec 22 08:57:41 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E861A1A9C for ; Mon, 22 Dec 2014 08:57:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.579
X-Spam-Level: *
X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPHo4bs5SJ9r for ; Mon, 22 Dec 2014 08:57:38 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99321A19FE for ; Mon, 22 Dec 2014 08:57:38 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64575 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y36IZ-0006R7-9f for dime@ietf.org; Mon, 22 Dec 2014 08:57:37 -0800
Message-ID: <54984D7E.3010405@usdonovans.com>
Date: Mon, 22 Dec 2014 10:57:34 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/h_510A9Ehh86_gwH291m_dSXFvM
Subject: [Dime] Handling of mandatory sub-avps
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Dec 2014 16:57:39 -0000

All,

The following is an open issue from Ben's suggested editorial changes 
that still needs to be addressed.

Regards,

Steve
>> -- 4.3, para 4:
>>
>> We should clarify that this is talking about mandatory to understand for DOIC, but not for the enclosing transaction.
> SRD> i'm not clear on what you are suggesting.

We need to be clear that receiving a DOIC avp with a mandatory AVP that you don't understand means you ignore the DOIC AVPs, but does not cause the Diameter transaction to fail. Or was it your intent to allow an application to say that if you get a DOIC avp that you can't process, you have to fail the Diameter transaction?

>   Do you have suggested wording?

Depends on the answer to the question above.


From nobody Mon Dec 22 08:57:52 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9921A1AA3 for ; Mon, 22 Dec 2014 08:57:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.579
X-Spam-Level: *
X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpltIePNqRKH for ; Mon, 22 Dec 2014 08:57:44 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869B21A1AA2 for ; Mon, 22 Dec 2014 08:57:44 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64576 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y36Ig-0006cM-HR for dime@ietf.org; Mon, 22 Dec 2014 08:57:43 -0800
Message-ID: <54984D85.905@usdonovans.com>
Date: Mon, 22 Dec 2014 10:57:41 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/4S0hpb25XNFz7txvAY5xpsOrmag
Subject: [Dime] OCS handling (from Ben's suggested editorial changes)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Dec 2014 16:57:45 -0000

All,

These are two related items from Ben's suggested editorial changes that 
still need to be resolved.

Regards,

Steve

>> -- 4.2.1.1, para 1:
>>
>> Do I understand correctly that the reacting node only keeps OCS for those combinations that it has actually received an OLR for? If so, that's not clear from the wording.
> SRD> Do you have suggested wording?

It depends. Does a reacting node keep OCS when it hasn't received an OLR?

If no:

"A reacting node SHOULD maintain the following OCS for each active OLR it receives per Diameter application..."

if yes:

Then I think the section needs some more thought to distinguish between what is stored for OLRs, vs when no OLR is received.

Also, I think the preface to the second bullet list seems wrong. I don't see how you could make an implementation work right without at least keeping sequence number and expiration time, at least when you have an active OLR.



>> -- 4.2.1.2, para 1:
>>
>> Likewise, the reporting node only keeps OCS for actual overload conditions where it sends OLRs?
> SRD> Do you have suggested wording?

This seems dependent on the same question as for the last comment. But assuming it only has to keep state of actual OLRs:

"A reporting node SHOULD maintain OCS entries for each OLR it sends, per ..."



From nobody Mon Dec 22 12:24:54 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531311A6F62 for ; Mon, 22 Dec 2014 12:24:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66TmtHdm24jL for ; Mon, 22 Dec 2014 12:24:47 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B485A1A6F10 for ; Mon, 22 Dec 2014 12:24:46 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 7A1BEB147720A for ; Mon, 22 Dec 2014 20:24:40 +0000 (GMT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sBMKOiaA028355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Dec 2014 21:24:44 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.50]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 22 Dec 2014 21:24:44 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org list" 
Thread-Topic: [Dime] DOIC WGLC: Editorial Comments
Thread-Index: AQHQGaX2yBuizEzFP0uz7fxPPCNUpZyT6HGAgAGygDA=
Date: Mon, 22 Dec 2014 20:24:43 +0000
Message-ID: 
References: <79E0AA6A-8F91-45FD-AE8A-EFF9D2A4E9D3@nostrum.com> <5491AEC7.8070307@usdonovans.com>
In-Reply-To: <5491AEC7.8070307@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/b7Ffi7UTXXifUpbyOi8AhwLbQ3g
Subject: Re: [Dime] DOIC WGLC: Editorial Comments
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Dec 2014 20:24:52 -0000

Dear all

Hereafter some comments (with JJ>)on some of the points discussed between B=
en and Steve. They are not essential
=20

-- section 3.1, 3rd paragraph: "Reporting nodes also include overload repor=
ts..."

"Reporting nodes _may_ also include overload reports..."=20
JJ> The "may" is ambiguous as there is a SHOULD in 4.2.3 when an active OCS=
. For my clarification, has a "may" in lower case a different meaning from =
a MAY in upper case. To be only descriptive as with 1st sentence of the par=
agraph : eg " Reporting nodes communicate overload occurrences by sending t=
he OLR AVP in answers (coming from 3.4, para 4".=20

 [...]

-- section 3.3, general:

Much of this section is redundant to stuff in the parent section. (**JJ sec=
tion 3)I suggest reducing the parent section detail, and keeping it here. (=
This may be true for subsequent children of section 3.) (**JJ effectively, =
but may need significant modifications )=20
SRD> Do you have specific suggestions?
Ben> Remove the 2nd to last and 3rd to last paragraph in 3.0.
JJ> OK but in 3.3 to use the text of the removed paragraphs from 3.0 for ho=
st report as well as for realm report

 [...]
=20

-- 4.1.3, para 9: "ambiguity"

I'm not sure that's is the word we want here. An agent could muck things up=
 without being ambiguous. Perhaps "inconsistency"?=20
SRD> The point is that the reacting nodes and reporting nodes must
unambiguously know what to do.  I think ambiguous is the right word

Ben> I can construct behavior that is not ambiguous to upstream or downstre=
am nodes, but still breaks normative requirements. How about " ... ensure t=
hat it does not introduce incorrect behavior for either the upstream or dow=
nstream DOIC nodes."

JJ> as Ben, ambiguity is not so right.=20
A proposal: "When making changes to the OC-Supported-Features or OC-OLR AVP=
s, the Diameter Agent needs to ensure  consistency in its behavior with bot=
h upstream and downstream DOIC nodes".
=09

-- 4.2.1.1, para 1:

Do I understand correctly that the reacting node only keeps OCS for those c=
ombinations that it has actually received an OLR for? If so, that's not cle=
ar from the wording.=20
SRD> Do you have suggested wording?
Ben> It depends. Does a reacting node keep OCS when it hasn't received an O=
LR?

If no:

"A reacting node SHOULD maintain the following OCS for each active OLR it r=
eceives per Diameter application..."

if yes:

Then I think the section needs some more thought to distinguish between wha=
t is stored for OLRs, vs when no OLR is received.

Also, I think the preface to the second bullet list seems wrong. I don't se=
e how you could make an implementation work right without at least keeping =
sequence number and expiration time, at least when you have an active OLR.

JJ>  my point would be to describe in 4.2.1.3 when an OCS is created / dele=
ted (as in 4.2.1.4 for Reporting node which addresses the creation of an OC=
S, deletion should also be added))
About the MAY in the preface to the second bullet list, to a have a SHOULD =
in line with 1st paragraph statement "the A reacting node SHOULD maintain t=
he following OCS..." As it is implementation, there were remarks that vario=
us ways can  address the OCS or equivalent  handling

[...]

-- 4.2.1.3, para 2:

Should this combination include origin-host or origin-realm? App-Id?=20
SRD> I don't understand this.
JJ> not sure we need additional text as it is elsewhere described the match=
ing of an OLR to an OCS

[...]

 -- 4.2.2, 2nd to last para:
=20
I think we need something a bit stronger here. The endpoint needs to take s=
ome action that makes sense for the application. The details of that are be=
yond our scope, but the general need is not.
SRD> We cannot enforce application behavior in a Diameter specification.   =
I don't see the need for anything more .  Do you have suggested wording?

Ben> Diameter endpoints that throttle requests [ MUST /need to ] do so acco=
rding to the rules of the client application. Those rules will vary by appl=
ication, and are beyond the scope of this document.
SRD> Ok, without the MUST

JJ> We have in the same section:.: "The abatement treatment applied depends=
 on the context of the request". We can write "...depends on the applicatio=
n and on the context of the request". Is it not enough?

[...]

-- 4.2.3, para 2:

Doesn't this also need to match the scope for the request type? E.g. Destin=
ation realm or destination host? For example, a host report for host A woul=
d not match OCS for host B, even though both had the same report type and a=
pplication id.=20
SRD> I guess this matters when an agent is the reporting node

Ben> I think it matters the same if the reporting node is an endpoint. For =
example, would you consider a host-routed-request with D-H: "foo" to match =
an host report for host "bar"?  (I'm on the fence here whether that is corr=
ect behavior, but I think the behavior should be the same for endpoints and=
 agents.)

Actually, on reflection, how does this affect the scenario of an agent that=
 passes through a host report and generates a realm report? Or a server tha=
t generates both?

SRD> Yes, I believe it does.  I suggest we delete paragraph 2, as the
criteria for matching an OCS will be report type dependent.

JJ>  here 4.2.3 is for the reporting node behavior. It was discussed a whil=
e ago if the OCS in the reporting node  was per client (so taking into acco=
unt the Origin Host of the request or an  OCS common to all clients, so ind=
ependent of the Origin Host of the request and with the same OLR sent to al=
l clients. The second option (common OCS)  was retained for this draft. The=
 OCS per client would be an option for a further extension.  Si I am OK wit=
h the current wording.

-- 4.2.3, last para:

An example of what we have in mind could be helpful here.
SRD> I'm open to suggested wording...

Ben> Add "For example, it might wait some period of time after overload end=
s before terminating the OLR, or it might send a series of OLRs indicating =
progressively less overload severity."
SRD> Ok

JJ>  Avoiding  oscillation is an important requirement of RFC7068  and this=
 sentence is one in the draft dealing with oscillations.?  A basic oscillat=
ion case is the following one, can we a text (in fact a guidance ) on this/=
 point. There are also som=F9e relma	ted qtement in=20
"e.g a reporting node having requested a strong traffic reduction, then nor=
mally a bit later may observe that it is no more overloaded due to the redu=
ced  traffic received, but it should not immediately send an OLR with a sma=
ll traffic reduction or even terminates the overload condition as this will=
 most probably again result in a strong increase of the incoming traffic as=
 no more reduced, so creating an oscillation."
This point is somewhat also addressed in the two last paragraphs of 5, in t=
he context of the loss algorithm. This oscillation aspect is more general a=
nd so be addressed in this 4.2.3 section

[...]

-- 4.3, para 4:=20
We should clarify that this is talking about mandatory to understand for DO=
IC, but not for the enclosing transaction.

SRD> i'm not clear on what you are suggesting.

Ben> We need to be clear that receiving a DOIC avp with a mandatory AVP tha=
t you don't understand means you ignore the DOIC AVPs, but does not cause t=
he Diameter transaction to fail. Or was it your intent to allow an applicat=
ion to say that if you get a DOIC avp that you can't process, you have to f=
ail the Diameter transaction?

SRD> This requires discussion on the list.  I'll start a thread.

JJ> In OC-Supported-Features AVP sent by reacting node, no bit in the OC-Fe=
ature-Vector is mandatory except the bit for loss algorithm support. Then i=
f there are additional AVPs in the OC-Supported-Features AVP, they can be i=
gnored except if they are related to a particular feature bit in the OC-Fea=
ture-Vector which make this additional AVP mandatory to be supported if the=
 feature is supported by the reporting node.  In any case, the request shou=
ld not fail.
If the OLR AVP contains new AVPs, this will be also related to the correspo=
nding feature bit that, if supported,  may require the new AVP be  mandator=
y in the OLRS sent back by the reporting node.. This will be part of the ne=
w feature description introducing additional AVPs. So I do not think we nee=
d to say more in this draft. This will be in the extension.

[...]

-- 5.1, para 4:

Convoluted paragraph. How about "How about "reporting nodes request the sta=
teless reduction of the number of requests by an indicated percentage."=20
SRD> Ok.=20
JJ> OK on Ben wording but "stateless" can be removed as  mentioned earlier =
in the section and not directly linked to this sentence.=20

Then about "...to what the reacting node otherwise would have sent" , this =
point, I think, is described in 5.3 paragraph 4


Best regards

JJacques=20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9=A0: mercredi 17 d=E9cembre 2014 17:27
=C0=A0: dime@ietf.org
Objet=A0: Re: [Dime] DOIC WGLC: Editorial Comments


On 12/16/14, 9:02 PM, Ben Campbell wrote:
> Here's some nits, editorial, and structural comments that are generally n=
on-substantive. With the possible exception of comments about 2119 language=
, most of these could be ignored without consequence, but I think we'd have=
 a better document if we at least thought about them:
>
> -- General:
>
> We keep referring to the DOIC "solution". I think "mechanism" is more app=
ropriate. I would think of a DOIC "solution" as a deployment that leverages=
 the DOIC "mechanism".
SRD> I don't see an issue here, as long as we are consistent.
>
> We overuse the word Diameter in front of other things. E.g. Diameter node=
s, Diameter Agents, Diameter clients, Diameter servers, etc. This entire dr=
aft is about Diameter; we don't have to keep saying it. It tends to get awk=
ward when we use it a lot in close proximity.
SRD> This was done based on feedback from Benoit.  We are being
explicit.  If there are paragraphs where it is particularly cumbersome, ple=
ase point out those paragraphs and we can try to make them less cumbersome.
>
> Should we put consistently quotes around "loss" when we describe the "los=
s" algorithm?
>
> -- Requirements (2119 language section)
>
> This is oddly placed. I'm used to seeing that after the introduction, eit=
her stand-alone or as part of a larger terminology section. The RFC editor =
recommends putting it as section 2.
SRD> Ok.
>
> -- section 2, Abatement Algorithm: "A mechanism..."
>
> I suggest "An extensible mechanism..."
SRD> Ok.
>
> -- Section 2, Diversion:
>
> Still needs work.  the "by selecting" phrase needs to indicate what does =
the selecting. "Path" should probably be "path or destination".
>
> Proposed text:
>
> "An overload abatement mechanism, where the reacting node selects alterna=
te destinations or paths for for requests."
SRD> I'm ok with this wording.
>
> -- section 2, OCS: "Reporting and reacting node internally maintained sta=
te..."
>
> I suggest "Internal state maintained by a reporting or reacting node..."
SRD> Ok.
>
> -- section 2, Realm-Routed Requests: "... does not know the host that wil=
l service..."
>
> I suggest: "... does not know which host will service ..."
SRD> Ok.
>
> We should also add a comment that it may be possible to apply diversion t=
o realm routed requests.
SRD> Where?
>
> -- section 2, Throttling: " ... a Diameter Client not sending requests...=
"
>
> I suggest " ... a Client choosing to not send requests ..."
SRD> A Diameter Client...
>
> -- section 3, 2nd paragraph:
>
> Client, servers, and agents should not be capitalized. Should "Reporting =
node" and "Reacting node" be hyphenated?  Consider moving the last sentence=
 to the start of the next paragraph.
SRD> The capitalization of Diameter Clients, Diameter Servers and
Diameter agents was Benoit's suggestion to make it explicit what is being r=
eferred to.  I don't see the need for hyphenation in this context.  I'm ok =
with moving the sentence.
>
> -- section 3.1, paragraph 1: " This is made possible by adding overload c=
ontrol AVPs, the OC-OLR AVP and the OC- Supported-Features AVP, as optional=
 AVPs into existing commands..."
>
> I suggest "This is made possible by adding the optional overload control =
AVPs OC-OLR and OC-Supported-Features into existing commands."
SRD> OK.
>
> -- section 3.1, 3rd paragraph: "Reporting nodes also include overload rep=
orts..."
>
> "Reporting nodes _may_ also include overload reports..."
SRD> OK.
>
> -- section 3.1, 4th paragraph: "Clients MAY report..."
>
> Should not be normative in this section.
SRD> Agreed.
>
> -- section 3.2, 6th paragraph: "The OC-Feature-Vector AVP will contain...=
"
>
> "... will _always_ contain..."
SRD> Ok.
>
> -- section 3.2, 7th paragraph: " ... all answer messages to requests ..."
>
> suggest "... all answers to requests..."
SRD> Ok.
>
> -- section 3.2, paragraph 9: "Reporting nodes are allowed to..."
>
> "Reporting nodes can..."
SRD> Ok.
>
> Also consider clarifying that they can change algorithms _between_transac=
tions_, as long as there's no active overload condition.
>
> -- section 3.2, paragraph 10 (starting with "The individual features..."
>
> Consider moving this entire paragraph to earlier in the section.
>
> -- section 3.2, paragraph 11: "The DCA mechanism must also allow..."
SRD> This paragraph looks redundant.  I suggest removing it.
>
> --> "The DCA mechanism allows..."
>
> "... the agent updates the OC-Supported-Features..." --> " ... the agent =
can update the OC-Supported-Features..."
SRD> Ok.
>
> -- section 3.3, general:
>
> Much of this section is redundant to stuff in the parent section. I=20
> suggest reducing the parent section detail, and keeping it here. (This=20
> may be true for subsequent children of section 3.)
SRD> Do you have specific suggestions?
>
> -- 3.3, third paragraph:
>
> s/ , / : /
SRD> I don't agree.  The commas are there because it is a list.
>
> -- 3.3, paragraph 4:
>
> In this overview, I suggest text saying that HOST_REPORT indicates a=20
> host report, and just using the term "host report" the rest of the=20
> time. (Same for realm report)
SRD> Why?
>
> -- 3.3, para 7: "A host-report, for instance, will generally by generated=
 by tracking utilization of resources..."
>
> I suggest "A host-report might be generated by tracking use of resources.=
.."
SRD> OK.
>
> -- 3.3, para 9: " ... are responsible for applying the overload abatement=
 algorithm..."
>
> I suggest " ... apply the abatement algorithm..."
SRD> Ok.
>
> -- 3.4, para 2: " ... the definition of new report types and the definiti=
on of new scopes ..."
>
> Aren't these sort of the same thing? That is, you add new scopes by exten=
ding report type?
SRD> Can't you have a how report that applies only to sessions on that host=
?
>
> -- 3.4, para 3:
>
> First two sentences are a bit confusing. A new reader will likely think t=
hey contradict, without some explanation that OC-Feature-Vector is a child =
of OC-S-F.
SRD> They seam clear to me.  Do you have a suggested clarification?
>
> -- 3.4, para 4:
>
> First sentence has already been stated more than once. No need to repeat =
here.
SRD> The first sentence is there to provide context for the second
sentence.
>
> -- 4.1.1, Para 1: "It MAY include the OC-Feature-Vector AVP."
>
> consider adding  ", as a sub-avp of OC-Supported-Features."
SRD> OK
>
> - 4.1.1, last paragraph: "This behavior is described in ..."
>
> What is the antecedent to "this"? If it's "loss algorithm" behavior, then=
 the reference to section 4.2 should not be needed.
SRD> Agreed.
>
> -- 4.1.2, para 2:
>
> It's probably worth reiterating that the reacting node may not be the ser=
ver, and this requirement may mean inserting AVPS into answers that came fr=
om upstream.
SRD> I don't see the need.  Do you have suggested wording?
>
> -- 4.1.2, para 3: "...response messages ... "
>
> "... _answer_ messages ..."
SRD> OK.
>
> -- 4.1.2, para 7: "If it selects a different algorithm, it MUST...:
>
> This is also true if it needs to announce some other feature that needs t=
o be indicated.
SRD> This paragraph is talking specifically about algorithms and is
needed because the AVP is optional.  Are you suggesting another sentence, a=
nother paragraph?  I'm guessing that the case you talk about is already cov=
ered elsewhere.
>
> -- 4.1.3, para 3: "... Agent MUST include OC-Supported-Features in reques=
t messages it receives..."
>
> I suspect this should say "... requests that it _forwards_" or "_relays_"=
.
SRD> To differentiate between the requests that it rejects.  Ok, I think
relays is the better word.
>
> -- 4.1.3, para 5 and 6:
>
> Is the reporting node section limited to endpoints? If not, the these par=
agraphs effectively restate normative language about reporting node behavio=
r from that section. Once we've said what a reporting node normatively has =
to do, we should just be able to say that an agent acting as a reporting no=
de has all the responsibilities of a reporting node, and not restate the no=
rmative requirements.
SRD> I'm ok with this but it feels like more than an editorial change to me=
.
>
> -- 4.1.3, para 7:
>
> The first MAY is a consequence (the complement) of the 2nd MAY. It should=
 at least not be 2119 language, and probably can be omitted entirely.
SRD> Do you have suggested wording?
>
> -- 4.1.3, para 9, last sentence:
>
> Does this mean an agent can only change OC-S-F in an answer if it changed=
 it in the request? I don't think we want that restriction, but the context=
 and "as such," seem to scope the MAY to that situation.
SRD> I don't read it that way.  The first sentence is describing one
reason why an agent might change OC-S-F.  It doesn't say it is the only rea=
son.
>
> -- 4.1.3, para 9: "ambiguity"
>
> I'm not sure that's is the word we want here. An agent could muck things =
up without being ambiguous. Perhaps "inconsistency"?
SRD> The point is that the reacting nodes and reporting nodes must
unambiguously know what to do.  I think ambiguous is the right word.
>
> -- 4.2.1.1, para 1:
>
> Do I understand correctly that the reacting node only keeps OCS for those=
 combinations that it has actually received an OLR for? If so, that's not c=
lear from the wording.
SRD> Do you have suggested wording?
>
> -- 4.2.1.2, para 1:
>
> Likewise, the reporting node only keeps OCS for actual overload condition=
s where it sends OLRs?
SRD> Do you have suggested wording?
>
> -- 4.2.1.3, para 2:
>
> Should this combination include origin-host or origin-realm? App-Id?
SRD> I don't understand this.
>
> -- 4.2.1.3,  para 3: ... a reporting node MUST process..."
>
> Should that be "reacting node"?
SRD> Yes.
>
> -- 4.2.1.3, para 4:
>
> Paragraph does not make sense. (I think we've already discussed this one =
from Ulrich's comments).
SRD> Yes, this is addressed already.
>
> -- 4.2.1.3, 3rd para from end: "... update the OCS entry as being expired=
."
>
> I suggest language like " invalid" or "terminated". I take "expired"=20
> to mean "naturally expired", which is different from the case=20
> described here. There may be subtle behavior difference. (For example,=20
> a reacting node might choose to log "expirations" differently than=20
> "explicit terminations".)
SRD> For the context of this specification I think expired works. =20
Implementations can differentiate types of expired if they have a reason.  =
Nothing here prevents that.
>
> -- 4.2.1.4, para 9: "... including the reduction percentage..."
>
> I suggest "... including, for example, the reduction percentage..."
SRD> OK.
>
> -- 4.2.1.4, para 11: " ... MUST update the sequence number ..."
>
> I suggest s / update / increment
SRD> OK.
>
> -- 4.2.2, 2nd to last para:
>
>   I think we need something a bit stronger here. The endpoint needs to ta=
ke some action that makes sense for the application. The details of that ar=
e beyond our scope, but the general need is not.
SRD> We cannot enforce application behavior in a Diameter
specification.   I don't see the need for anything more .  Do you have=20
suggested wording?
>
> -- 4.2.3, para 2:
>
> Doesn't this also need to match the scope for the request type? E.g. Dest=
ination realm or destination host? For example, a host report for host A wo=
uld not match OCS for host B, even though both had the same report type and=
 application id.
SRD> I guess this matters when an agent is the reporting node.
>
> -- 4.2.3, paras 8 and 9:
>
> We put the currently less favored approach first, with the favored approa=
ch in the following paragraph. I suggest we put the more favored approach f=
irst.
SRD> OK.
>
>
> -- 4.2.3, last para:
>
> An example of what we have in mind could be helpful here.
SRD> I'm open to suggested wording...
>
>
> -- 4.3, para 4:
>
> We should clarify that this is talking about mandatory to understand for =
DOIC, but not for the enclosing transaction.
SRD> i'm not clear on what you are suggesting.  Do you have suggested
wording?
>
> -- 4.3, para 5:
>
> Why is it different depending on whether the feature is an algorithm or n=
ot? Also, isn't this mostly redundant to the paragraph about new normative =
behavior?
SRD> I agree, this paragraph can be removed.
>
> -- 4.3, para 6, last sentence
>
> This is redundant to earlier normative language in the section=20
> (assuming a new report type will always involve new normative=20
> behavior.)
SRD> I agree, the last sentence can be removed.
>
> -- 4.3, para 7, last sentence
>
> Also redundant
SRD> Agreed.
>
> -- 4.3, last para, last sentence:
>
> It's not clear if this means section 8 of this doc, or 6733. I suggest pu=
tting this sentence before the subsequent one.
SRD> OK.
>
> -- 5.1, para 4:
>
> Convoluted paragraph. How about "How about "reporting nodes request the s=
tateless reduction of the number of requests by an indicated percentage."
SRD> Ok.
>
> We should also clarify that this reduction is in comparison to what the r=
eacting node otherwise would have sent, rather than what it may have previo=
usly sent.
SRD> Isn't this already covered?  Do you have suggested wording?
>
> -- 5.3, para 5:
>
> Needs a sentence or paragraph to describe the 100% issue before describin=
g how to back down from it.
SRD> It's discussed earlier in the document.  I'm ok with adding it
again.  Do you have suggested wording?
>
> "... following concerns are RECOMMENDED ..."
>
> following procedures...?
SRD> OK.
>
> -- 5.3, para 6: "... does not receive an OLR in messages sent to the form=
erly overloaded node..."
>
> Do we mean "... does not receive an OLR in answers received from the form=
erly overloaded node..."?
SRD> Agreed.
>
> -- para 6, last paragraph
>
> Paragraph is off topic for section. It probably belongs in the extensibil=
ity section, or at least somewhere other than here.
SRD> Do you mean section 6? This isn't about extensibility but about how
Diameter applications integrate DOIC.  It probably belongs in the intro or =
overview sections.
>
> -- 6.1, last para:
>
> I think we moved this to 6.2, but forgot to delete it here.
SRD> Yup, already addressed as part of Ulrich's comments.
>
> -- 6.2:
>
> Why did the AVP code jump to TBD6? (Also seems out of order in the=20
> table.)
SRD> Historical reasons.  Doesn't matter, the real values will be filled
in eventually.
>
> Is it to late to rename the value to OLR_LOSS_ALGO?
SRD> Yes. :-)
>
> -- 9.4, para 2: "A node MUST not..."
>
> "A node MUST _NOT_ ..."
SRD> Ok.
>
> -- References:
>
> 5905 and 5729 are not cited in the document.
SRD> Ok.
>
> draft-ietf-dime-e2e-sec-req-00: Outdated version.
SRD> Ok.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Mon Dec 22 13:54:48 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341981A87BC for ; Mon, 22 Dec 2014 13:54:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6Iefp8Cdt34 for ; Mon, 22 Dec 2014 13:54:33 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7403F1A87B1 for ; Mon, 22 Dec 2014 13:54:33 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id C60B3F139ECF8; Mon, 22 Dec 2014 21:54:26 +0000 (GMT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sBMLsUwc032641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Dec 2014 22:54:31 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.50]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 22 Dec 2014 22:54:30 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] DOIC WGLC: loss algorithm behavior with expiring OLRs
Thread-Index: AQHQGbdrUj+bYvNyikSS1OtMbZBuSZyTzAwAgAhjEGA=
Date: Mon, 22 Dec 2014 21:54:29 +0000
Message-ID: 
References: <94CD92E2-B801-4EC4-BECE-5C2B0788B361@nostrum.com> <54919712.6040007@usdonovans.com>
In-Reply-To: <54919712.6040007@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/H7lnjZba-uWpLOKny3DAMhiU8tY
Subject: Re: [Dime] DOIC WGLC: loss algorithm behavior with expiring OLRs
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Dec 2014 21:54:39 -0000

Dear all

I think good to give guidance, so I ma not in favor to strike out the indic=
ated text.=20

I suggest to keep paragraphs but to re-structure them  by starting with a g=
eneral statement.
Proposal:=20

   When an active overload report expires, it is suggested that the
   reacting node progressively decrease the amount of traffic given
   abatement treatment, until the reduction is completely removed and no
   traffic is given abatement treatment.

      The goal of this behavior is to reduce the probability of overload
      condition thrashing where an immediate transition from 100%a high per=
centage
      reduction to 0% reduction results in the reporting node moving
      quickly back into an overload condition, so creating an oscillation

   If reacting node comes out of the 100 percent traffic reduction as a
   result of the overload report timing out, the following concerns are
   RECOMMENDED to be applied.  The reacting node sending the traffic
   should be conservative and, for example, first send "probe" messages
   to learn the overload condition of the overloaded node before
   converging to any traffic amount/rate decided by the sender.  Similar
   concerns apply in all cases when the overload report times out unless
   the previous overload report stated 0 percent reduction.

Best regards

JJacques=20

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9=A0: mercredi 17 d=E9cembre 2014 15:46
=C0=A0: dime@ietf.org
Objet=A0: Re: [Dime] DOIC WGLC: loss algorithm behavior with expiring OLRs

I agree.  In addition, the explanatory paragraph that follows should be mov=
ed to after the paragraph that discusses behavior after 100% reduction.

Steve

On 12/16/14, 11:07 PM, Ben Campbell wrote:
> Section 5.3 (paragraph 7) says that, for the loss algorithm, a reacting n=
ode should slowly ramp back up if an OLR expires. This seems to be for the =
general case of expiring loss-algorithm OLRs, since the case of expiring 10=
0% reduction OLRs was dealt with in the preceding paragraphs.
>
> We have guidance elsewhere that a _reporting_node_ should end an overload=
 condition in a controlled fashion. If both the reacting node and reporting=
 node are trying to do this, you may get unexpected behavior. It makes sens=
e for the reacting node to ramp up slowly from 100% reduction, since the re=
porting node could not update the reduction percentage until expired. But f=
or an percentage reduction that still allows non-trivial traffic, the repor=
ting node should be gradually ramping down the reduction.
>
> I propose we strike the entire paragraph from section 5.3.
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Mon Dec 22 13:54:49 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476531A87B1 for ; Mon, 22 Dec 2014 13:54:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4at24OE9rTfo for ; Mon, 22 Dec 2014 13:54:39 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6831A87B9 for ; Mon, 22 Dec 2014 13:54:39 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 6E36F395BD343; Mon, 22 Dec 2014 21:54:34 +0000 (GMT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sBMLsa5U026710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Dec 2014 22:54:37 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.50]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 22 Dec 2014 22:54:36 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: Ben Campbell , "dime@ietf.org list" , "draft-ietf-dime-ovli@tools.ietf.org" 
Thread-Topic: [Dime] DOIC WGLC: Implicit values for OC-OLR
Thread-Index: AQHQGbf2bZ2gL/fZykiN9F7smW2hfpyTSssAgAjh18A=
Date: Mon, 22 Dec 2014 21:54:36 +0000
Message-ID: 
References: <93DEBE9A-62A4-4637-9BF8-FFCD4195B115@nostrum.com> <54912AA6.2080706@gmail.com>
In-Reply-To: <54912AA6.2080706@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iqvM9wShYpocHSGynP2TEj6rR6Q
Subject: Re: [Dime] DOIC WGLC: Implicit values for OC-OLR
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Dec 2014 21:54:42 -0000

Hi

I think we can keep the current text as a general statement. This  does not=
 prevmrt from indicating  more explicit meaning in future extensions if nee=
ded.

Best regards

JJacques=20

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
Envoy=E9=A0: mercredi 17 d=E9cembre 2014 08:03
=C0=A0: Ben Campbell; dime@ietf.org list; draft-ietf-dime-ovli@tools.ietf.o=
rg
Objet=A0: Re: [Dime] DOIC WGLC: Implicit values for OC-OLR

OK with me.

- Jouni

12/17/2014 7:11 AM, Ben Campbell kirjoitti:
> (No, this is not the general rant on implicit values you from me :-)  )
>
> In section 6.3, paragraph 1, we have the following sentence:
>
> " The OC-OLR AVP does not explicitly contain all information needed by th=
e reacting node to decide whether a subsequent request must undergo abateme=
nt using the received reduction percentage."
>
> I think this may vary by report type. For example, peer reports might nee=
d to include at least  some things explicitly that are implicit for host an=
d realm reports. It's even different between host and realm reports. Theref=
ore, I think we should remove it from this section, and put the specifics i=
n the description of each report type.
>
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Mon Dec 22 13:59:41 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF831A8786 for ; Mon, 22 Dec 2014 13:59:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5A51FShQXYW for ; Mon, 22 Dec 2014 13:59:33 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DF8C1A87D0 for ; Mon, 22 Dec 2014 13:59:32 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id BBA018AD694AF; Mon, 22 Dec 2014 21:59:27 +0000 (GMT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sBMLxUgY028542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Dec 2014 22:59:30 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.50]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 22 Dec 2014 22:59:30 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: Ben Campbell , "Wiehe, Ulrich (NSN - DE/Munich)" 
Thread-Topic: [Dime] DOIC WGLC: duration unit
Thread-Index: AQHQGbXE0uLPAUv+M0uSCJqeZtsDhJyTyBAAgAAhXYCAAAObgIAADKaAgAAUDACAAAZ5AIAAQlCAgAABzgCAAS7BAIAAbpoAgAYxImA=
Date: Mon, 22 Dec 2014 21:59:30 +0000
Message-ID: 
References: <0AF415BD-4AA8-4A4F-942B-29DA6C9E417B@nostrum.com> <549193B8.6000603@usdonovans.com>  <5491B2BB.30709@usdonovans.com> <3543DB65-DFC1-4ADE-8808-7B931F325F92@nostrum.com> <5491CE28.2020205@usdonovans.com> <0E11AEDD-6E90-4D61-8759-557B8596BAFB@nostrum.com> <54920B37.4060201@gmail.com> <2BE199F8-262D-40AB-A567-A857E94B3A6A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D900066815235C94@DEMUMBX014.nsn-intra.net> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/o74FMWxB2EBinBwATXVyFt2aBrI
Cc: "dime@ietf.org" 
Subject: Re: [Dime] DOIC WGLC: duration unit
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Dec 2014 21:59:38 -0000

Dear all

I am also ,in favor  to take the second as unit (according to Ben 's argume=
nts), and also to have a upper limit. The limit that Ben gives is about 50 =
days. Is 24 hours too short? =20

Best regards

JJacques=20

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell
Envoy=E9=A0: vendredi 19 d=E9cembre 2014 00:47
=C0=A0: Wiehe, Ulrich (NSN - DE/Munich)
Cc=A0: dime@ietf.org
Objet=A0: Re: [Dime] DOIC WGLC: duration unit

Hi Ulrich,

You bring up a good point that we need to document the limits, or at least =
describe the implications of choosing to long or short of a duration either=
 way. I suspect 1s is still too short for most situations, and  ( 2^32 - 1 =
/ 1000 )s is probably still too long.

(Don't get me wrong; I still think millisecond resolution for this is silly=
.)

Thanks!

Ben.

> On Dec 18, 2014, at 11:11 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:
>=20
> Ben,
>=20
> my inclination is to change back to seconds. However, seconds allow a max=
imum value that is 1000 times higher and may be regarded unreasonably high.=
 In a previous version of the draft we had an upper limit, and maybe when g=
oing back to seconds we should re-introduce an upper limit so that the prot=
ocol does not allow unreasonably long durations.
>=20
> Ulrich
>=20
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
> Sent: Thursday, December 18, 2014 12:08 AM
> To: Jouni Korhonen
> Cc: dime@ietf.org
> Subject: Re: [Dime] DOIC WGLC: duration unit
>=20
>=20
>> On Dec 17, 2014, at 5:01 PM, Jouni Korhonen  wro=
te:
>>=20
>> [snip]
>>=20
>>>> I'll step out of the argument and let someone else be champion for mil=
lisecond granularity.
>>>=20
>>> Any other takers? Are there real use cases for sub-second precision?
>>=20
>> I do not really care. We changed that from seconds to milliseconds for s=
ome reason.. but no not see a reason to change it back either.
>=20
> I'd argue that we should make it the "right thing", regardless of whether=
 we changed it before. (Although remembering why might go far to answering =
my last question below.)
>=20
> I've describe why I think it is false precision, and can become harmful. =
To rephrase it, choosing too small of durations will cause harm by forcing =
rapid OLR updates (as in many per second.) These updates cause work for bot=
h reporting nodes and reacting nodes.=20
>=20
> We could offer guidance of how to avoid that harm. Or we could choose a r=
esolution that makes it harder to cause such harm in the first place. I thi=
nk good protocol design favors the later.
>=20
> Do you disagree with the potential for harm? Or do you see some use case =
for sub-second precision that I've missed?
>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Mon Dec 22 16:11:22 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C990E1A88DD for ; Mon, 22 Dec 2014 16:11:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlEZbTCgi1Ls for ; Mon, 22 Dec 2014 16:11:19 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6A11A1B8B for ; Mon, 22 Dec 2014 16:11:18 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBN0BHJu072345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2014 18:11:18 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <54984D31.5000201@usdonovans.com>
Date: Mon, 22 Dec 2014 18:11:17 -0600
X-Mao-Original-Outgoing-Id: 440986277.247434-92feb2b001fbde5684433a64d3f3d8e7
Content-Transfer-Encoding: quoted-printable
Message-Id: <00328701-E938-444C-B8BC-ADBE05B201CB@nostrum.com>
References: <79E0AA6A-8F91-45FD-AE8A-EFF9D2A4E9D3@nostrum.com> <5491AEC7.8070307@usdonovans.com>  <54984D31.5000201@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ny1NK4Q85rBsUVNa3ENX6Tcqw6A
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: Editorial Comments
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Dec 2014 00:11:21 -0000

Hi, I've removed sections that seem to need no further discussion, where =
you've suggested moving to separate threads, or where I'm just gonna =
roll over :-)

> On Dec 22, 2014, at 10:56 AM, Steve Donovan  =
wrote:

[...]
>>>> -- 4.1.2, para 7: "If it selects a different algorithm, it MUST...:
>>>>=20
>>>> This is also true if it needs to announce some other feature that =
needs to be indicated.
>>> SRD> This paragraph is talking specifically about algorithms and is =
needed because the AVP is optional.  Are you suggesting another =
sentence, another paragraph?  I'm guessing that the case you talk about =
is already covered elsewhere.
>> We say this in 4.1.1 on reacting node behavior. We should make the =
same statement for reporting node behavior. This is the definitive =
section on reporting node behavior. If it's repeated elsewhere, we =
should consider whether _that_ text is redundant.
> SRD> Again, this paragraph is dealing specifically with rules around =
which the algorithms supported by the reporting node interact with the =
OC-Features-Vector AVP.  The statement on other features is three =
paragraphs later.

If you mean this paragraph:

"  The reporting node SHOULD indicate support for other DOIC features
   defined in extension drafts that it supports and that apply to the
   transaction."

Nothing in that (3 paragraphs later) paragraph says you MUST include =
OC-Features-Vector to do that. It's left for the reader to infer. We do =
explicitly say that for reacting nodes in 4.1.1.

[...]



From nobody Mon Dec 22 16:16:00 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D17C1A88A3 for ; Mon, 22 Dec 2014 16:15:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TC-mPFdpl8JH for ; Mon, 22 Dec 2014 16:15:58 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 734C81A8935 for ; Mon, 22 Dec 2014 16:15:51 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBN0Fohs072712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2014 18:15:51 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <54984D7E.3010405@usdonovans.com>
Date: Mon, 22 Dec 2014 18:15:50 -0600
X-Mao-Original-Outgoing-Id: 440986549.9985-4e70048062e57898dc336c46a740612e
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <54984D7E.3010405@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/71J5ylbLiAORp10DtIxJsRf9iJk
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Handling of mandatory sub-avps
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Dec 2014 00:15:59 -0000

My opinion is that any DOIC error (i.e. something wrong in OC-S-F or =
OC-OLR) should never cause an error or other failure of the enclosing =
transaction. Normally the only way DOIC should affect a transaction is =
via abatement.

I would grudgingly accept the ability for a Diameter application spec to =
say that the application must not be used without DOIC (and potentially =
certain DOIC features.), as long as such a requirement was explicit =
(including explicit on _how_ it should fail), but I think that's a =
different use case.

> On Dec 22, 2014, at 10:57 AM, Steve Donovan  =
wrote:
>=20
> All,
>=20
> The following is an open issue from Ben's suggested editorial changes =
that still needs to be addressed.
>=20
> Regards,
>=20
> Steve
>>> -- 4.3, para 4:
>>>=20
>>> We should clarify that this is talking about mandatory to understand =
for DOIC, but not for the enclosing transaction.
>> SRD> i'm not clear on what you are suggesting.
>=20
> We need to be clear that receiving a DOIC avp with a mandatory AVP =
that you don't understand means you ignore the DOIC AVPs, but does not =
cause the Diameter transaction to fail. Or was it your intent to allow =
an application to say that if you get a DOIC avp that you can't process, =
you have to fail the Diameter transaction?
>=20
>>  Do you have suggested wording?
>=20
> Depends on the answer to the question above.
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Mon Dec 22 18:34:11 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694C51ACD22 for ; Mon, 22 Dec 2014 18:34:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ks7epj51lt4I for ; Mon, 22 Dec 2014 18:34:08 -0800 (PST)
Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 481A41ACC8A for ; Mon, 22 Dec 2014 18:34:08 -0800 (PST)
Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id f94d8945.0.6965957.00-2260.19525020.nbfkord-smmo07.seg.att.com (envelope-from );  Tue, 23 Dec 2014 02:34:08 +0000 (UTC)
X-MXL-Hash: 5498d4a01cc9e377-260d4d7d4d30b7c23bde123c6d683dcc46b972ac
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id sBN2Y67L008099; Mon, 22 Dec 2014 21:34:07 -0500
Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id sBN2Xx9T008074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Dec 2014 21:34:02 -0500
Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Tue, 23 Dec 2014 02:33:42 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.24]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0195.001; Mon, 22 Dec 2014 21:33:42 -0500
From: "DOLLY, MARTIN C" 
To: Ben Campbell , Steve Donovan 
Thread-Topic: [Dime] Handling of mandatory sub-avps
Thread-Index: AQHQHkWm1Hzyl/BwKEaPle6SD7NOQJycdRdQ
Date: Tue, 23 Dec 2014 02:33:41 +0000
Message-ID: 
References: <54984D7E.3010405@usdonovans.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.83.201]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=PLW4D4WC c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a]
X-AnalysisOut: [=TS_NFkrObDAA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP]
X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=A92cGCtB03wA:10 a=48vgC7mUA]
X-AnalysisOut: [AAA:8 a=yakATiurAAAA:8 a=RzrZFk0ni7BOwH-jkGoA:9 a=CjuIK1q_]
X-AnalysisOut: [8ugA:10]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.24]
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/VExBJTEiAWMXJdI7Y-XsBVyEPYg
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Handling of mandatory sub-avps
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Dec 2014 02:34:10 -0000

NO, WRONG

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: Monday, December 22, 2014 7:16 PM
To: Steve Donovan
Cc: dime@ietf.org
Subject: Re: [Dime] Handling of mandatory sub-avps

My opinion is that any DOIC error (i.e. something wrong in OC-S-F or OC-OLR=
) should never cause an error or other failure of the enclosing transaction=
. Normally the only way DOIC should affect a transaction is via abatement.

I would grudgingly accept the ability for a Diameter application spec to sa=
y that the application must not be used without DOIC (and potentially certa=
in DOIC features.), as long as such a requirement was explicit (including e=
xplicit on _how_ it should fail), but I think that's a different use case.

> On Dec 22, 2014, at 10:57 AM, Steve Donovan  wr=
ote:
>=20
> All,
>=20
> The following is an open issue from Ben's suggested editorial changes tha=
t still needs to be addressed.
>=20
> Regards,
>=20
> Steve
>>> -- 4.3, para 4:
>>>=20
>>> We should clarify that this is talking about mandatory to understand fo=
r DOIC, but not for the enclosing transaction.
>> SRD> i'm not clear on what you are suggesting.
>=20
> We need to be clear that receiving a DOIC avp with a mandatory AVP that y=
ou don't understand means you ignore the DOIC AVPs, but does not cause the =
Diameter transaction to fail. Or was it your intent to allow an application=
 to say that if you get a DOIC avp that you can't process, you have to fail=
 the Diameter transaction?
>=20
>>  Do you have suggested wording?
>=20
> Depends on the answer to the question above.
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Mon Dec 22 18:42:36 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E271ACD2F for ; Mon, 22 Dec 2014 18:42:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6bjcj_6vxwn for ; Mon, 22 Dec 2014 18:42:32 -0800 (PST)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21FD41ACD23 for ; Mon, 22 Dec 2014 18:42:32 -0800 (PST)
Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-2) over TLS secured channel with ESMTP id 696d8945.0.6890541.00-2386.19291247.nbfkord-smmo05.seg.att.com (envelope-from );  Tue, 23 Dec 2014 02:42:32 +0000 (UTC)
X-MXL-Hash: 5498d6984fa580a6-56703f8a08fb005ddedc195aecee6460442fb586
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id sBN2gUwq012353; Mon, 22 Dec 2014 21:42:30 -0500
Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id sBN2gMv4012323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Dec 2014 21:42:23 -0500
Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 23 Dec 2014 02:42:15 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.24]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0195.001; Mon, 22 Dec 2014 21:42:15 -0500
From: "DOLLY, MARTIN C" 
To: Ben Campbell , Steve Donovan 
Thread-Topic: [Dime] Handling of mandatory sub-avps
Thread-Index: AQHQHkWm1Hzyl/BwKEaPle6SD7NOQJycdRdQgAACEqA=
Date: Tue, 23 Dec 2014 02:42:14 +0000
Message-ID: 
References: <54984D7E.3010405@usdonovans.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.83.201]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=Mu/lHRme c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a]
X-AnalysisOut: [=TS_NFkrObDAA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP]
X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=A92cGCtB03wA:10 a=48vgC7mUA]
X-AnalysisOut: [AAA:8 a=yakATiurAAAA:8 a=uyiPKUS2nzlFUDwHSoQA:9 a=CjuIK1q_]
X-AnalysisOut: [8ugA:10 a=2TSDkfqdCjIA:10 a=XNiWMx5388f8oGVo:21 a=R2NCGlxD]
X-AnalysisOut: [FCkZQmKr:21]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.24]
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/GfynZRiHRfmdHqEvYElpyzmD_tA
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Handling of mandatory sub-avps
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Dec 2014 02:42:34 -0000

To be clear, ignore what one does not understand.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C
Sent: Monday, December 22, 2014 9:34 PM
To: Ben Campbell; Steve Donovan
Cc: dime@ietf.org
Subject: Re: [Dime] Handling of mandatory sub-avps

*** Security Advisory: This Message Originated Outside of AT&T ***.
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.

NO, WRONG

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: Monday, December 22, 2014 7:16 PM
To: Steve Donovan
Cc: dime@ietf.org
Subject: Re: [Dime] Handling of mandatory sub-avps

My opinion is that any DOIC error (i.e. something wrong in OC-S-F or OC-OLR=
) should never cause an error or other failure of the enclosing transaction=
. Normally the only way DOIC should affect a transaction is via abatement.

I would grudgingly accept the ability for a Diameter application spec to sa=
y that the application must not be used without DOIC (and potentially certa=
in DOIC features.), as long as such a requirement was explicit (including e=
xplicit on _how_ it should fail), but I think that's a different use case.

> On Dec 22, 2014, at 10:57 AM, Steve Donovan  wr=
ote:
>=20
> All,
>=20
> The following is an open issue from Ben's suggested editorial changes tha=
t still needs to be addressed.
>=20
> Regards,
>=20
> Steve
>>> -- 4.3, para 4:
>>>=20
>>> We should clarify that this is talking about mandatory to understand fo=
r DOIC, but not for the enclosing transaction.
>> SRD> i'm not clear on what you are suggesting.
>=20
> We need to be clear that receiving a DOIC avp with a mandatory AVP that y=
ou don't understand means you ignore the DOIC AVPs, but does not cause the =
Diameter transaction to fail. Or was it your intent to allow an application=
 to say that if you get a DOIC avp that you can't process, you have to fail=
 the Diameter transaction?
>=20
>>  Do you have suggested wording?
>=20
> Depends on the answer to the question above.
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


From nobody Mon Dec 22 20:34:31 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6F81A0087 for ; Mon, 22 Dec 2014 20:34:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5-tsmZyDlwl for ; Mon, 22 Dec 2014 20:34:27 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23FFF1A008A for ; Mon, 22 Dec 2014 20:34:27 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBN4YKbF093046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2014 22:34:24 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Ben Campbell 
X-Mailer: iPad Mail (12B440)
In-Reply-To: 
Date: Mon, 22 Dec 2014 22:34:22 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <26D1E2EC-3DF6-487C-980F-F6DBE6EFDF39@nostrum.com>
References: <54984D7E.3010405@usdonovans.com>   
To: "DOLLY, MARTIN C" 
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/jEOy0H1_Dlkip4gPqWX9_SKLs48
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Handling of mandatory sub-avps
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Dec 2014 04:34:29 -0000

Martin, I think we are violently agreeing. A DOIC "failure" doesn't impact t=
he Diameter transaction.


> On Dec 22, 2014, at 8:42 PM, DOLLY, MARTIN C  wrote:
>=20
> To be clear, ignore what one does not understand.
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C
> Sent: Monday, December 22, 2014 9:34 PM
> To: Ben Campbell; Steve Donovan
> Cc: dime@ietf.org
> Subject: Re: [Dime] Handling of mandatory sub-avps
>=20
> *** Security Advisory: This Message Originated Outside of AT&T ***.
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.=

>=20
> NO, WRONG
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
> Sent: Monday, December 22, 2014 7:16 PM
> To: Steve Donovan
> Cc: dime@ietf.org
> Subject: Re: [Dime] Handling of mandatory sub-avps
>=20
> My opinion is that any DOIC error (i.e. something wrong in OC-S-F or OC-OL=
R) should never cause an error or other failure of the enclosing transaction=
. Normally the only way DOIC should affect a transaction is via abatement.
>=20
> I would grudgingly accept the ability for a Diameter application spec to s=
ay that the application must not be used without DOIC (and potentially certa=
in DOIC features.), as long as such a requirement was explicit (including ex=
plicit on _how_ it should fail), but I think that's a different use case.
>=20
>> On Dec 22, 2014, at 10:57 AM, Steve Donovan  wr=
ote:
>>=20
>> All,
>>=20
>> The following is an open issue from Ben's suggested editorial changes tha=
t still needs to be addressed.
>>=20
>> Regards,
>>=20
>> Steve
>>>> -- 4.3, para 4:
>>>>=20
>>>> We should clarify that this is talking about mandatory to understand fo=
r DOIC, but not for the enclosing transaction.
>>> SRD> i'm not clear on what you are suggesting.
>>=20
>> We need to be clear that receiving a DOIC avp with a mandatory AVP that y=
ou don't understand means you ignore the DOIC AVPs, but does not cause the D=
iameter transaction to fail. Or was it your intent to allow an application t=
o say that if you get a DOIC avp that you can't process, you have to fail th=
e Diameter transaction?
>>=20
>>> Do you have suggested wording?
>>=20
>> Depends on the answer to the question above.
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Tue Dec 23 04:36:24 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1662A1ACE71 for ; Tue, 23 Dec 2014 04:36:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJJGpwXCGCqb for ; Tue, 23 Dec 2014 04:36:13 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F56B1ACE03 for ; Tue, 23 Dec 2014 04:30:43 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBNCUeKV012917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Dec 2014 12:30:40 GMT
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBNCUcvt029842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Dec 2014 13:30:38 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 23 Dec 2014 13:30:38 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.60]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0195.001; Tue, 23 Dec 2014 13:30:38 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , Ben Campbell 
Thread-Topic: [Dime] Ulrich's suggested change #15
Thread-Index: AQHQE7dJhQB5e1nbwEev114RSsJu35yHeSWggAL2Z7uAAD8mAIAACZWAgAY/jwCAAU9ggIABPegggAglTQCAAYF28A==
Date: Tue, 23 Dec 2014 12:30:37 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815239CB6@DEMUMBX014.nsn-intra.net>
References: <5486FE71.70205@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235215@DEMUMBX014.nsn-intra.net> <54884137.4050209@usdonovans.com> <5AB8BAC5-3CBD-432E-9631-74DF40795844@nostrum.com> <5489A498.5070203@usdonovans.com>  <5489EFAF.8010702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152358E0@DEMUMBX014.nsn-intra.net> <549046D3.3090104@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235AB9@DEMUMBX014.nsn-intra.net> <549826C8.1090809@usdonovans.com>
In-Reply-To: <549826C8.1090809@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.124]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D900066815239CB6DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 24590
X-purgate-ID: 151667::1419337840-00002DC5-73ECAE05/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KN8LPGOAKXb5snPQ1-aHgtNYQjg
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #15
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Dec 2014 12:36:20 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D900066815239CB6DEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

No, that was not what I'm after.

Imagine the (unlikely) case where an answer message contains hundreds of OC=
-OLR AVPs.

In this case I want the reacting node to be allowed

-          Not to scan through all the OC-OLR AVPs to see whether there is =
a supported  and not duplicated OLR

-          To ignore the complete set of OC-OLR AVPs if at least one of the=
 OLR contains an unsupported report-type or at least two of the OLRs contai=
n  the same report type.

As soon as the reacting node detects that there is something wrong with the=
 set of OLRs it may ignore the complete set of OLRs.

Regards
Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, December 22, 2014 3:12 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
Cc: dime@ietf.org
Subject: Re: [Dime] Ulrich's suggested change #15

I have added the following statements:

   When receiving an answer message with multiple OLRs and multiple of

   the OLRs are of the same supported report types, a reporting node

   SHOULD ignore the duplicated OLRs.



   A reacting node SHOULD ignore an OC-OLR with a OC-Report-Type AVP

   that contains an unrecognized value.
Regards,

Steve
On 12/17/14 2:49 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Yes please.



-----Original Message-----

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]

Sent: Tuesday, December 16, 2014 3:51 PM

To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell

Cc: dime@ietf.org

Subject: Re: [Dime] Ulrich's suggested change #15



I'll delete the paragraph.



Do we need explicit statements for the two conditions below?



Steve





On 12/15/14, 11:56 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Steve, Ben,



I'm fine with deleting the paragraph.

But for my clarification please confirm that ignoring the complete set of O=
LRs is allowed when one of these OLRs contains a report type that was not a=
dvertized, or two of the OLRs contain the same report type.



Regards

Ulrich







-----Original Message-----

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]

Sent: Thursday, December 11, 2014 8:26 PM

To: Ben Campbell

Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] Ulrich's suggested change #15





On 12/11/14, 12:51 PM, Ben Campbell wrote:

On Dec 11, 2014, at 8:05 AM, Steve Donovan  wrote:



I thought this paragraph was covering unrecognized values for all AVPs.

I agree that's what it covered. But I think we failed to cover the unrecogn=
ized AVP case. If we don't have anything to say beyond what 6733 says, then=
 it might not be strictly necessary, but it might still be worth saying tha=
t "unrecognized sub-AVPs are treated as per RFC6733".

That is probably worth saying.

   Maybe it is better to remove the paragraph entirely and make sure that t=
he definition of each AVP addresses what is done with unrecognized values.

Possibly. There are AVPs where there's no such thing as an unrecognized val=
ue. There may be AVPs where the allowed values vary by algorithm. If we do =
take that route, we probably need language here that says unrecognized valu=
es are handled as described by the AVP definition or the algorithm.

Agreed.

Steve



On 12/10/14, 5:26 PM, Ben Campbell wrote:

On Dec 10, 2014, at 6:48 AM, Steve Donovan  wrote:



Ulrich,



Actually, the wording you suggested wasn't quite right.  It should be:



    When receiving an OC-OLR AVP with unknown values, the overload report

    SHOULD be silently discarded by reacting nodes and the event SHOULD

    be logged.



It's not just about report type values but unknown values for any of the AV=
Ps in the OLR.



This seems like a good requirement to include in the specification to ensur=
e common behavior in reacting nodes.  I don't feel strongly about this but =
I would like to hear other opinions.

I think this is still not quite complete.



If you receive a sub-AVP that you don't understand, then you should ignore =
that sub-avp, not the whole OC-OLR AVP.  (Unless of course the unknown AVP =
has the m-bit set.) If you receive a known sub-AVP, with a value you don't =
understand, the behavior should be AVP specific. For Report-Type, that mean=
s ignore the whole OLR.



It's not clear to me whether the original text was about arbitrary avps, or=
 Report-Type.



Steve



On 12/9/14, 11:04 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Hi Steve,



I think it was pointed out by Ben that we do not specify behaviour of a nod=
e for cases where it detects that another node is breaking the rule.

The rule is:

     A reporting node MUST NOT send overload reports of a type that has

     not been advertised as supported by the reacting node.

See section 4.2.3.



Regards

Ulrich



    From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donova=
n

Sent: Tuesday, December 09, 2014 2:52 PM

To: dime@ietf.org

Subject: [Dime] Ulrich's suggested change #15



Ulrich,



For your suggested change #15:

Section 4.2.1.3, 4th paragraph:

Existing text:

     When receiving an OC-OLR AVPs with unknown values, a reacting node

     SHOULD be silently discarded by reacting nodes and the event SHOULD

     be logged.

Comment: text is confusing. Maybe the intention was to say:

     When receiving an OC-OLR AVPs with an unsupported report type value, a=
 reacting node

     SHOULD silently discarded the OC-OLR AVP and the event SHOULD

     be logged.

But even that is not correct.

Proposal: Remove the paragraph.

The intent was that an OC-OLR that contains unknown values should be discar=
ded.  I agree that the wording needs to be changes as you suggested.  I don=
't agree with removing the paragraph.  Can you elaborate on why you think i=
t is not correct when changed as you suggested?



Regards,



Steve



_______________________________________________

DiME mailing list

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime








--_000_5BCBA1FC2B7F0B4C9D935572D900066815239CB6DEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











No, that w=
as not what I’m after.


 =
;


Imagine th=
e (unlikely) case where an answer message contains hundreds of OC-OLR AVPs.=



 =
;


In this ca=
se I want the reacting node to be allowed


-         
No=
t to scan through all the OC-OLR AVPs to see whether there is a supported&n=
bsp; and not duplicated OLR


-         
To=
 ignore the complete set of OC-OLR AVPs if at least one of the OLR contains=
 an unsupported report-type or at least two of the OLRs
 contain  the same report type.


 =
;


As soon as=
 the reacting node detects that there is something wrong with the set of OL=
Rs it may ignore the complete set of OLRs.


 =
;


Regards


Ulrich


 =
;






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Monday, December 22, 2014 3:12 PM

To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell

Cc: dime@ietf.org

Subject: Re: [Dime] Ulrich's suggested change #15<=
/p>





 


I have added the foll=
owing statements:


   When receiving an answer message with multiple OLRs and m=
ultiple of


   the OLRs are of the same supported report types, a report=
ing node


   SHOULD ignore the duplicated OLRs.


 


   A reacting node SHOULD ignore an OC-OLR with a OC-Report-=
Type AVP


   that contains an unrecognized value.


Regards,



Steve




On 12/17/14 2:49 AM, Wiehe, Ulrich (NSN - DE/Munich)=
 wrote:






Yes please.


 


-----Original Message-----


From: ext Steve Donovan [m=
ailto:srdonovan@usdonovans.com] 


Sent: Tuesday, December 16, 2014 3:51 PM


To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell


Cc: dime@ietf.org

Subject: Re: [Dime] Ulrich's suggested change #15


 


I'll delete the paragraph.


 


Do we need explicit statements for the two conditions below?


 


Steve


 


 


On 12/15/14, 11:56 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:




Steve, Ben,


 


I'm fine with deleting the paragraph.


But for my clarification please confirm that ignoring the complete set=
 of OLRs is allowed when one of these OLRs contains a report type that was =
not advertized, or two of the OLRs contain the same report type.=



 


Regards


Ulrich


 


 


 


-----Original Message-----


From: ext Steve Donovan [m=
ailto:srdonovan@usdonovans.com]


Sent: Thursday, December 11, 2014 8:26 PM


To: Ben Campbell


Cc: Wiehe, Ulrich (NSN - DE/Munich); =
dime@ietf.org


Subject: Re: [Dime] Ulrich's suggested change #15


 


 


On 12/11/14, 12:51 PM, Ben Campbell wrote:






On Dec 11, 2014, at 8:05 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 


I thought this paragraph was covering unrecognized values for all AVPs=
.




I agree that's what it covered. But I think we failed to cover the unr=
ecognized AVP case. If we don't have anything to say beyond what 6733 says,=
 then it might not be strictly necessary, but it might still be worth sayin=
g that "unrecognized sub-AVPs are treated as per RFC6733".




That is probably worth saying.






   Maybe it is better to remove the paragraph entirely and m=
ake sure that the definition of each AVP addresses what is done with unreco=
gnized values.




Possibly. There are AVPs where there's no such thing as an unrecognize=
d value. There may be AVPs where the allowed values vary by algorithm. If w=
e do take that route, we probably need language here that says unrecognized=
 values are handled as described by the AVP definition or the algorithm.




Agreed.






Steve


 


On 12/10/14, 5:26 PM, Ben Campbell wrote:






On Dec 10, 2014, at 6:48 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 


Ulrich,


 


Actually, the wording you suggested wasn't quite right.  It shoul=
d be:


 


    When receiving an OC-OLR AVP with unknown values, t=
he overload report


    SHOULD be silently discarded by reacting nodes and =
the event SHOULD


    be logged.


 


It's not just about report type values but unknown values for any of t=
he AVPs in the OLR.


 


This seems like a good requirement to include in the specification to =
ensure common behavior in reacting nodes.  I don't feel strongly about=
 this but I would like to hear other opinions.




I think this is still not quite complete.


 


If you receive a sub-AVP that you don't understand, then you should ig=
nore that sub-avp, not the whole OC-OLR AVP.  (Unless of course the un=
known AVP has the m-bit set.) If you receive a known sub-AVP, with a value =
you don't understand, the behavior should be AVP specific. For Report-Type,=
 that means ignore the whole OLR.


 


It's not clear to me whether the original text was about arbitrary avp=
s, or Report-Type.


 




Steve


 


On 12/9/14, 11:04 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:




Hi Steve,


 


I think it was pointed out by Ben that we do not specify behaviour of =
a node for cases where it detects that another node is breaking the rule.


The rule is:


     A reporting node MUST NOT send overload repor=
ts of a type that has


     not been advertised as supported by the react=
ing node.


See section 4.2.3.


 


Regards


Ulrich


 


    From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan


Sent: Tuesday, December 09, 2014 2:52 PM


To: dime@ietf.org

Subject: [Dime] Ulrich's suggested change #15


 


Ulrich,


 


For your suggested change #15:


Section 4.2.1.3, 4th paragraph:


Existing text:


     When receiving an OC-OLR AVPs with unknown va=
lues, a reacting node


     SHOULD be silently discarded by reacting node=
s and the event SHOULD


     be logged.


Comment: text is confusing. Maybe the intention was to say:=



     When receiving an OC-OLR AVPs with an unsuppo=
rted report type value, a reacting node


     SHOULD silently discarded the OC-OLR AVP and =
the event SHOULD


     be logged.


But even that is not correct.


Proposal: Remove the paragraph.


The intent was that an OC-OLR that contains unknown values should be d=
iscarded.  I agree that the wording needs to be changes as you suggest=
ed.  I don't agree with removing the paragraph.  Can you elaborat=
e on why you think it is not correct when changed as you suggested?


 


Regards,


 


Steve


 




_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime










 




 


 




 






--_000_5BCBA1FC2B7F0B4C9D935572D900066815239CB6DEMUMBX014nsnin_--


From nobody Tue Dec 23 07:06:00 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41631ACF24 for ; Tue, 23 Dec 2014 07:05:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JodAO1r63uQ for ; Tue, 23 Dec 2014 07:05:55 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9B01ACF58 for ; Tue, 23 Dec 2014 07:05:53 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBNF5pnv052293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Dec 2014 09:05:52 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815239CB6@DEMUMBX014.nsn-intra.net>
Date: Tue, 23 Dec 2014 09:05:50 -0600
X-Mao-Original-Outgoing-Id: 441039949.602184-8e2b06cd155b65d43edcd75540cb8e30
Content-Transfer-Encoding: quoted-printable
Message-Id: <1FC86658-AB09-4C11-9ED1-0C7FAFC542BE@nostrum.com>
References: <5486FE71.70205@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235215@DEMUMBX014.nsn-intra.net> <54884137.4050209@usdonovans.com> <5AB8BAC5-3CBD-432E-9631-74DF40795844@nostrum.com> <5489A498.5070203@usdonovans.com>  <5489EFAF.8010702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152358E0@DEMUMBX014.nsn-intra.net> <549046D3.3090104@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235AB9@DEMUMBX014.nsn-intra.net> <549826C8.1090809@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815239CB6@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/c-zfVKEeOkaJt5TVPelh1jhS8_w
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #15
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Dec 2014 15:05:58 -0000

I don't object to allowing that behavior. But thinking of a less extreme =
case, where you have two OC-OLRs and only recognize one, I think it =
would be poor design to ignore the one you do recognize. OTOH, it's not =
the IETF's job to prevent bad design, as long as it's interoperable and =
doesn't break everyone else (and the network.)

But we might want to consider the fact that this puts the work upon the =
overloaded reporting node to make things right, rather than on the =
reacting node to figure it out. For example, the use cases I've describe =
in a separate thread, where you have multiple reacting nodes with =
different capabilities, might could be mitigated by allowing (not =
requiring) the reporting node put the OC-OLRs for both in each answer. =
We don't currently allow that unless they are different types, but I =
wonder if we should think about relaxing that.

> On Dec 23, 2014, at 6:30 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:
>=20
> No, that was not what I=E2=80=99m after.
> =20
> Imagine the (unlikely) case where an answer message contains hundreds =
of OC-OLR AVPs.
> =20
> In this case I want the reacting node to be allowed
> -          Not to scan through all the OC-OLR AVPs to see whether =
there is a supported  and not duplicated OLR
> -          To ignore the complete set of OC-OLR AVPs if at least one =
of the OLR contains an unsupported report-type or at least two of the =
OLRs contain  the same report type.
> =20
> As soon as the reacting node detects that there is something wrong =
with the set of OLRs it may ignore the complete set of OLRs.
> =20
> Regards
> Ulrich
> =20
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> Sent: Monday, December 22, 2014 3:12 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
> Cc: dime@ietf.org
> Subject: Re: [Dime] Ulrich's suggested change #15
> =20
> I have added the following statements:
>=20
>    When receiving an answer message with multiple OLRs and multiple of
>    the OLRs are of the same supported report types, a reporting node
>    SHOULD ignore the duplicated OLRs.
> =20
>    A reacting node SHOULD ignore an OC-OLR with a OC-Report-Type AVP
>    that contains an unrecognized value.
> Regards,
>=20
> Steve
>=20
> On 12/17/14 2:49 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Yes please.
> =20
> -----Original Message-----
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> Sent: Tuesday, December 16, 2014 3:51 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
> Cc: dime@ietf.org
> Subject: Re: [Dime] Ulrich's suggested change #15
> =20
> I'll delete the paragraph.
> =20
> Do we need explicit statements for the two conditions below?
> =20
> Steve
> =20
> =20
> On 12/15/14, 11:56 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve, Ben,
> =20
> I'm fine with deleting the paragraph.
> But for my clarification please confirm that ignoring the complete set =
of OLRs is allowed when one of these OLRs contains a report type that =
was not advertized, or two of the OLRs contain the same report type.
> =20
> Regards
> Ulrich
> =20
> =20
> =20
> -----Original Message-----
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> Sent: Thursday, December 11, 2014 8:26 PM
> To: Ben Campbell
> Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] Ulrich's suggested change #15
> =20
> =20
> On 12/11/14, 12:51 PM, Ben Campbell wrote:
> On Dec 11, 2014, at 8:05 AM, Steve Donovan  =
wrote:
> =20
> I thought this paragraph was covering unrecognized values for all =
AVPs.
> I agree that's what it covered. But I think we failed to cover the =
unrecognized AVP case. If we don't have anything to say beyond what 6733 =
says, then it might not be strictly necessary, but it might still be =
worth saying that "unrecognized sub-AVPs are treated as per RFC6733".
> That is probably worth saying.
>    Maybe it is better to remove the paragraph entirely and make sure =
that the definition of each AVP addresses what is done with unrecognized =
values.
> Possibly. There are AVPs where there's no such thing as an =
unrecognized value. There may be AVPs where the allowed values vary by =
algorithm. If we do take that route, we probably need language here that =
says unrecognized values are handled as described by the AVP definition =
or the algorithm.
> Agreed.
> Steve
> =20
> On 12/10/14, 5:26 PM, Ben Campbell wrote:
> On Dec 10, 2014, at 6:48 AM, Steve Donovan  =
wrote:
> =20
> Ulrich,
> =20
> Actually, the wording you suggested wasn't quite right.  It should be:
> =20
>     When receiving an OC-OLR AVP with unknown values, the overload =
report
>     SHOULD be silently discarded by reacting nodes and the event =
SHOULD
>     be logged.
> =20
> It's not just about report type values but unknown values for any of =
the AVPs in the OLR.
> =20
> This seems like a good requirement to include in the specification to =
ensure common behavior in reacting nodes.  I don't feel strongly about =
this but I would like to hear other opinions.
> I think this is still not quite complete.
> =20
> If you receive a sub-AVP that you don't understand, then you should =
ignore that sub-avp, not the whole OC-OLR AVP.  (Unless of course the =
unknown AVP has the m-bit set.) If you receive a known sub-AVP, with a =
value you don't understand, the behavior should be AVP specific. For =
Report-Type, that means ignore the whole OLR.
> =20
> It's not clear to me whether the original text was about arbitrary =
avps, or Report-Type.
> =20
> Steve
> =20
> On 12/9/14, 11:04 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Hi Steve,
> =20
> I think it was pointed out by Ben that we do not specify behaviour of =
a node for cases where it detects that another node is breaking the =
rule.
> The rule is:
>      A reporting node MUST NOT send overload reports of a type that =
has
>      not been advertised as supported by the reacting node.
> See section 4.2.3.
> =20
> Regards
> Ulrich
> =20
>     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve =
Donovan
> Sent: Tuesday, December 09, 2014 2:52 PM
> To: dime@ietf.org
> Subject: [Dime] Ulrich's suggested change #15
> =20
> Ulrich,
> =20
> For your suggested change #15:
> Section 4.2.1.3, 4th paragraph:
> Existing text:
>      When receiving an OC-OLR AVPs with unknown values, a reacting =
node
>      SHOULD be silently discarded by reacting nodes and the event =
SHOULD
>      be logged.
> Comment: text is confusing. Maybe the intention was to say:
>      When receiving an OC-OLR AVPs with an unsupported report type =
value, a reacting node
>      SHOULD silently discarded the OC-OLR AVP and the event SHOULD
>      be logged.
> But even that is not correct.
> Proposal: Remove the paragraph.
> The intent was that an OC-OLR that contains unknown values should be =
discarded.  I agree that the wording needs to be changes as you =
suggested.  I don't agree with removing the paragraph.  Can you =
elaborate on why you think it is not correct when changed as you =
suggested?
> =20
> Regards,
> =20
> Steve
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =20
> =20
> =20


From nobody Tue Dec 23 07:55:37 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132DD1A90CF for ; Tue, 23 Dec 2014 07:55:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKLwtnk0Q93n for ; Tue, 23 Dec 2014 07:55:31 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68E2A1A19EC for ; Tue, 23 Dec 2014 07:55:31 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBNFtSqA014769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Dec 2014 15:55:28 GMT
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBNFtRWh029281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Dec 2014 16:55:27 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.60]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0195.001; Tue, 23 Dec 2014 16:55:27 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Ben Campbell 
Thread-Topic: [Dime] Ulrich's suggested change #15
Thread-Index: AQHQE7dJhQB5e1nbwEev114RSsJu35yHeSWggAL2Z7uAAD8mAIAACZWAgAY/jwCAAU9ggIABPegggAglTQCAAYF28IAAH80AgAAaZ9A=
Date: Tue, 23 Dec 2014 15:55:26 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681523ACF5@DEMUMBX014.nsn-intra.net>
References: <5486FE71.70205@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235215@DEMUMBX014.nsn-intra.net> <54884137.4050209@usdonovans.com> <5AB8BAC5-3CBD-432E-9631-74DF40795844@nostrum.com> <5489A498.5070203@usdonovans.com>  <5489EFAF.8010702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152358E0@DEMUMBX014.nsn-intra.net> <549046D3.3090104@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235AB9@DEMUMBX014.nsn-intra.net> <549826C8.1090809@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815239CB6@DEMUMBX014.nsn-intra.net> <1FC86658-AB09-4C11-9ED1-0C7FAFC542BE@nostrum.com>
In-Reply-To: <1FC86658-AB09-4C11-9ED1-0C7FAFC542BE@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.111]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 10704
X-purgate-ID: 151667::1419350129-00001177-58E489EB/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/oza-xa7HTlJMRpTK8484Os5QfYU
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #15
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Dec 2014 15:55:36 -0000

V2hlbiB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgZG9pbmcgdGhpbmdzIHdyb25nLCBpLmUuIHNlbmRz
IGFuIE9MUiBvZiBhIHR5cGUgdGhhdCB3YXMgbm90IGFkdmVydGl6ZWQgKGltcGxpY2l0bHkgb3Ig
ZXhwbGljaXRseSksIG9yIHNlbmRzIHR3byBPTFJzIG9mIHNhbWUgdHlwZSwgYWx0aG91Z2ggdGhl
IHNwZWMgc2F5cyAiTVVTVCBOT1QgZG8gc28iLCB3ZSBjYW5ub3QgZXhwZWN0IHRoZSByZWFjdGlu
ZyBub2RlIHRvIHNvcnQgdGhpbmdzIG91dC4NCkkgZG8gbm90IGFncmVlIHRvIHJlbGF4IHRoZSAi
TVVTVCBOT1QgZG8gc28iIHJlcXVpcmVtZW50IGZvciB0aGUgcmVwb3J0aW5nIG5vZGUuDQoNCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGV4dCBCZW4gQ2FtcGJlbGwgW21haWx0
bzpiZW5Abm9zdHJ1bS5jb21dIA0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMjMsIDIwMTQgNDow
NiBQTQ0KVG86IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkNCkNjOiBleHQgU3RldmUg
RG9ub3ZhbjsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSBVbHJpY2gncyBzdWdn
ZXN0ZWQgY2hhbmdlICMxNQ0KDQpJIGRvbid0IG9iamVjdCB0byBhbGxvd2luZyB0aGF0IGJlaGF2
aW9yLiBCdXQgdGhpbmtpbmcgb2YgYSBsZXNzIGV4dHJlbWUgY2FzZSwgd2hlcmUgeW91IGhhdmUg
dHdvIE9DLU9MUnMgYW5kIG9ubHkgcmVjb2duaXplIG9uZSwgSSB0aGluayBpdCB3b3VsZCBiZSBw
b29yIGRlc2lnbiB0byBpZ25vcmUgdGhlIG9uZSB5b3UgZG8gcmVjb2duaXplLiBPVE9ILCBpdCdz
IG5vdCB0aGUgSUVURidzIGpvYiB0byBwcmV2ZW50IGJhZCBkZXNpZ24sIGFzIGxvbmcgYXMgaXQn
cyBpbnRlcm9wZXJhYmxlIGFuZCBkb2Vzbid0IGJyZWFrIGV2ZXJ5b25lIGVsc2UgKGFuZCB0aGUg
bmV0d29yay4pDQoNCkJ1dCB3ZSBtaWdodCB3YW50IHRvIGNvbnNpZGVyIHRoZSBmYWN0IHRoYXQg
dGhpcyBwdXRzIHRoZSB3b3JrIHVwb24gdGhlIG92ZXJsb2FkZWQgcmVwb3J0aW5nIG5vZGUgdG8g
bWFrZSB0aGluZ3MgcmlnaHQsIHJhdGhlciB0aGFuIG9uIHRoZSByZWFjdGluZyBub2RlIHRvIGZp
Z3VyZSBpdCBvdXQuIEZvciBleGFtcGxlLCB0aGUgdXNlIGNhc2VzIEkndmUgZGVzY3JpYmUgaW4g
YSBzZXBhcmF0ZSB0aHJlYWQsIHdoZXJlIHlvdSBoYXZlIG11bHRpcGxlIHJlYWN0aW5nIG5vZGVz
IHdpdGggZGlmZmVyZW50IGNhcGFiaWxpdGllcywgbWlnaHQgY291bGQgYmUgbWl0aWdhdGVkIGJ5
IGFsbG93aW5nIChub3QgcmVxdWlyaW5nKSB0aGUgcmVwb3J0aW5nIG5vZGUgcHV0IHRoZSBPQy1P
TFJzIGZvciBib3RoIGluIGVhY2ggYW5zd2VyLiBXZSBkb24ndCBjdXJyZW50bHkgYWxsb3cgdGhh
dCB1bmxlc3MgdGhleSBhcmUgZGlmZmVyZW50IHR5cGVzLCBidXQgSSB3b25kZXIgaWYgd2Ugc2hv
dWxkIHRoaW5rIGFib3V0IHJlbGF4aW5nIHRoYXQuDQoNCj4gT24gRGVjIDIzLCAyMDE0LCBhdCA2
OjMwIEFNLCBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIDx1bHJpY2gud2llaGVAbnNu
LmNvbT4gd3JvdGU6DQo+IA0KPiBObywgdGhhdCB3YXMgbm90IHdoYXQgSeKAmW0gYWZ0ZXIuDQo+
ICANCj4gSW1hZ2luZSB0aGUgKHVubGlrZWx5KSBjYXNlIHdoZXJlIGFuIGFuc3dlciBtZXNzYWdl
IGNvbnRhaW5zIGh1bmRyZWRzIG9mIE9DLU9MUiBBVlBzLg0KPiAgDQo+IEluIHRoaXMgY2FzZSBJ
IHdhbnQgdGhlIHJlYWN0aW5nIG5vZGUgdG8gYmUgYWxsb3dlZA0KPiAtICAgICAgICAgIE5vdCB0
byBzY2FuIHRocm91Z2ggYWxsIHRoZSBPQy1PTFIgQVZQcyB0byBzZWUgd2hldGhlciB0aGVyZSBp
cyBhIHN1cHBvcnRlZCAgYW5kIG5vdCBkdXBsaWNhdGVkIE9MUg0KPiAtICAgICAgICAgIFRvIGln
bm9yZSB0aGUgY29tcGxldGUgc2V0IG9mIE9DLU9MUiBBVlBzIGlmIGF0IGxlYXN0IG9uZSBvZiB0
aGUgT0xSIGNvbnRhaW5zIGFuIHVuc3VwcG9ydGVkIHJlcG9ydC10eXBlIG9yIGF0IGxlYXN0IHR3
byBvZiB0aGUgT0xScyBjb250YWluICB0aGUgc2FtZSByZXBvcnQgdHlwZS4NCj4gIA0KPiBBcyBz
b29uIGFzIHRoZSByZWFjdGluZyBub2RlIGRldGVjdHMgdGhhdCB0aGVyZSBpcyBzb21ldGhpbmcg
d3Jvbmcgd2l0aCB0aGUgc2V0IG9mIE9MUnMgaXQgbWF5IGlnbm9yZSB0aGUgY29tcGxldGUgc2V0
IG9mIE9MUnMuDQo+ICANCj4gUmVnYXJkcw0KPiBVbHJpY2gNCj4gIA0KPiBGcm9tOiBleHQgU3Rl
dmUgRG9ub3ZhbiBbbWFpbHRvOnNyZG9ub3ZhbkB1c2Rvbm92YW5zLmNvbV0gDQo+IFNlbnQ6IE1v
bmRheSwgRGVjZW1iZXIgMjIsIDIwMTQgMzoxMiBQTQ0KPiBUbzogV2llaGUsIFVscmljaCAoTlNO
IC0gREUvTXVuaWNoKTsgQmVuIENhbXBiZWxsDQo+IENjOiBkaW1lQGlldGYub3JnDQo+IFN1Ympl
Y3Q6IFJlOiBbRGltZV0gVWxyaWNoJ3Mgc3VnZ2VzdGVkIGNoYW5nZSAjMTUNCj4gIA0KPiBJIGhh
dmUgYWRkZWQgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnRzOg0KPiANCj4gICAgV2hlbiByZWNlaXZp
bmcgYW4gYW5zd2VyIG1lc3NhZ2Ugd2l0aCBtdWx0aXBsZSBPTFJzIGFuZCBtdWx0aXBsZSBvZg0K
PiAgICB0aGUgT0xScyBhcmUgb2YgdGhlIHNhbWUgc3VwcG9ydGVkIHJlcG9ydCB0eXBlcywgYSBy
ZXBvcnRpbmcgbm9kZQ0KPiAgICBTSE9VTEQgaWdub3JlIHRoZSBkdXBsaWNhdGVkIE9MUnMuDQo+
ICANCj4gICAgQSByZWFjdGluZyBub2RlIFNIT1VMRCBpZ25vcmUgYW4gT0MtT0xSIHdpdGggYSBP
Qy1SZXBvcnQtVHlwZSBBVlANCj4gICAgdGhhdCBjb250YWlucyBhbiB1bnJlY29nbml6ZWQgdmFs
dWUuDQo+IFJlZ2FyZHMsDQo+IA0KPiBTdGV2ZQ0KPiANCj4gT24gMTIvMTcvMTQgMjo0OSBBTSwg
V2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSB3cm90ZToNCj4gWWVzIHBsZWFzZS4NCj4g
IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBleHQgU3RldmUgRG9ub3Zh
biBbbWFpbHRvOnNyZG9ub3ZhbkB1c2Rvbm92YW5zLmNvbV0gDQo+IFNlbnQ6IFR1ZXNkYXksIERl
Y2VtYmVyIDE2LCAyMDE0IDM6NTEgUE0NCj4gVG86IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011
bmljaCk7IEJlbiBDYW1wYmVsbA0KPiBDYzogZGltZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog
W0RpbWVdIFVscmljaCdzIHN1Z2dlc3RlZCBjaGFuZ2UgIzE1DQo+ICANCj4gSSdsbCBkZWxldGUg
dGhlIHBhcmFncmFwaC4NCj4gIA0KPiBEbyB3ZSBuZWVkIGV4cGxpY2l0IHN0YXRlbWVudHMgZm9y
IHRoZSB0d28gY29uZGl0aW9ucyBiZWxvdz8NCj4gIA0KPiBTdGV2ZQ0KPiAgDQo+ICANCj4gT24g
MTIvMTUvMTQsIDExOjU2IEFNLCBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIHdyb3Rl
Og0KPiBTdGV2ZSwgQmVuLA0KPiAgDQo+IEknbSBmaW5lIHdpdGggZGVsZXRpbmcgdGhlIHBhcmFn
cmFwaC4NCj4gQnV0IGZvciBteSBjbGFyaWZpY2F0aW9uIHBsZWFzZSBjb25maXJtIHRoYXQgaWdu
b3JpbmcgdGhlIGNvbXBsZXRlIHNldCBvZiBPTFJzIGlzIGFsbG93ZWQgd2hlbiBvbmUgb2YgdGhl
c2UgT0xScyBjb250YWlucyBhIHJlcG9ydCB0eXBlIHRoYXQgd2FzIG5vdCBhZHZlcnRpemVkLCBv
ciB0d28gb2YgdGhlIE9MUnMgY29udGFpbiB0aGUgc2FtZSByZXBvcnQgdHlwZS4NCj4gIA0KPiBS
ZWdhcmRzDQo+IFVscmljaA0KPiAgDQo+ICANCj4gIA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KPiBGcm9tOiBleHQgU3RldmUgRG9ub3ZhbiBbbWFpbHRvOnNyZG9ub3ZhbkB1c2Rvbm92
YW5zLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDExLCAyMDE0IDg6MjYgUE0NCj4g
VG86IEJlbiBDYW1wYmVsbA0KPiBDYzogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsg
ZGltZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0RpbWVdIFVscmljaCdzIHN1Z2dlc3RlZCBj
aGFuZ2UgIzE1DQo+ICANCj4gIA0KPiBPbiAxMi8xMS8xNCwgMTI6NTEgUE0sIEJlbiBDYW1wYmVs
bCB3cm90ZToNCj4gT24gRGVjIDExLCAyMDE0LCBhdCA4OjA1IEFNLCBTdGV2ZSBEb25vdmFuIDxz
cmRvbm92YW5AdXNkb25vdmFucy5jb20+IHdyb3RlOg0KPiAgDQo+IEkgdGhvdWdodCB0aGlzIHBh
cmFncmFwaCB3YXMgY292ZXJpbmcgdW5yZWNvZ25pemVkIHZhbHVlcyBmb3IgYWxsIEFWUHMuDQo+
IEkgYWdyZWUgdGhhdCdzIHdoYXQgaXQgY292ZXJlZC4gQnV0IEkgdGhpbmsgd2UgZmFpbGVkIHRv
IGNvdmVyIHRoZSB1bnJlY29nbml6ZWQgQVZQIGNhc2UuIElmIHdlIGRvbid0IGhhdmUgYW55dGhp
bmcgdG8gc2F5IGJleW9uZCB3aGF0IDY3MzMgc2F5cywgdGhlbiBpdCBtaWdodCBub3QgYmUgc3Ry
aWN0bHkgbmVjZXNzYXJ5LCBidXQgaXQgbWlnaHQgc3RpbGwgYmUgd29ydGggc2F5aW5nIHRoYXQg
InVucmVjb2duaXplZCBzdWItQVZQcyBhcmUgdHJlYXRlZCBhcyBwZXIgUkZDNjczMyIuDQo+IFRo
YXQgaXMgcHJvYmFibHkgd29ydGggc2F5aW5nLg0KPiAgICBNYXliZSBpdCBpcyBiZXR0ZXIgdG8g
cmVtb3ZlIHRoZSBwYXJhZ3JhcGggZW50aXJlbHkgYW5kIG1ha2Ugc3VyZSB0aGF0IHRoZSBkZWZp
bml0aW9uIG9mIGVhY2ggQVZQIGFkZHJlc3NlcyB3aGF0IGlzIGRvbmUgd2l0aCB1bnJlY29nbml6
ZWQgdmFsdWVzLg0KPiBQb3NzaWJseS4gVGhlcmUgYXJlIEFWUHMgd2hlcmUgdGhlcmUncyBubyBz
dWNoIHRoaW5nIGFzIGFuIHVucmVjb2duaXplZCB2YWx1ZS4gVGhlcmUgbWF5IGJlIEFWUHMgd2hl
cmUgdGhlIGFsbG93ZWQgdmFsdWVzIHZhcnkgYnkgYWxnb3JpdGhtLiBJZiB3ZSBkbyB0YWtlIHRo
YXQgcm91dGUsIHdlIHByb2JhYmx5IG5lZWQgbGFuZ3VhZ2UgaGVyZSB0aGF0IHNheXMgdW5yZWNv
Z25pemVkIHZhbHVlcyBhcmUgaGFuZGxlZCBhcyBkZXNjcmliZWQgYnkgdGhlIEFWUCBkZWZpbml0
aW9uIG9yIHRoZSBhbGdvcml0aG0uDQo+IEFncmVlZC4NCj4gU3RldmUNCj4gIA0KPiBPbiAxMi8x
MC8xNCwgNToyNiBQTSwgQmVuIENhbXBiZWxsIHdyb3RlOg0KPiBPbiBEZWMgMTAsIDIwMTQsIGF0
IDY6NDggQU0sIFN0ZXZlIERvbm92YW4gPHNyZG9ub3ZhbkB1c2Rvbm92YW5zLmNvbT4gd3JvdGU6
DQo+ICANCj4gVWxyaWNoLA0KPiAgDQo+IEFjdHVhbGx5LCB0aGUgd29yZGluZyB5b3Ugc3VnZ2Vz
dGVkIHdhc24ndCBxdWl0ZSByaWdodC4gIEl0IHNob3VsZCBiZToNCj4gIA0KPiAgICAgV2hlbiBy
ZWNlaXZpbmcgYW4gT0MtT0xSIEFWUCB3aXRoIHVua25vd24gdmFsdWVzLCB0aGUgb3ZlcmxvYWQg
cmVwb3J0DQo+ICAgICBTSE9VTEQgYmUgc2lsZW50bHkgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5v
ZGVzIGFuZCB0aGUgZXZlbnQgU0hPVUxEDQo+ICAgICBiZSBsb2dnZWQuDQo+ICANCj4gSXQncyBu
b3QganVzdCBhYm91dCByZXBvcnQgdHlwZSB2YWx1ZXMgYnV0IHVua25vd24gdmFsdWVzIGZvciBh
bnkgb2YgdGhlIEFWUHMgaW4gdGhlIE9MUi4NCj4gIA0KPiBUaGlzIHNlZW1zIGxpa2UgYSBnb29k
IHJlcXVpcmVtZW50IHRvIGluY2x1ZGUgaW4gdGhlIHNwZWNpZmljYXRpb24gdG8gZW5zdXJlIGNv
bW1vbiBiZWhhdmlvciBpbiByZWFjdGluZyBub2Rlcy4gIEkgZG9uJ3QgZmVlbCBzdHJvbmdseSBh
Ym91dCB0aGlzIGJ1dCBJIHdvdWxkIGxpa2UgdG8gaGVhciBvdGhlciBvcGluaW9ucy4NCj4gSSB0
aGluayB0aGlzIGlzIHN0aWxsIG5vdCBxdWl0ZSBjb21wbGV0ZS4NCj4gIA0KPiBJZiB5b3UgcmVj
ZWl2ZSBhIHN1Yi1BVlAgdGhhdCB5b3UgZG9uJ3QgdW5kZXJzdGFuZCwgdGhlbiB5b3Ugc2hvdWxk
IGlnbm9yZSB0aGF0IHN1Yi1hdnAsIG5vdCB0aGUgd2hvbGUgT0MtT0xSIEFWUC4gIChVbmxlc3Mg
b2YgY291cnNlIHRoZSB1bmtub3duIEFWUCBoYXMgdGhlIG0tYml0IHNldC4pIElmIHlvdSByZWNl
aXZlIGEga25vd24gc3ViLUFWUCwgd2l0aCBhIHZhbHVlIHlvdSBkb24ndCB1bmRlcnN0YW5kLCB0
aGUgYmVoYXZpb3Igc2hvdWxkIGJlIEFWUCBzcGVjaWZpYy4gRm9yIFJlcG9ydC1UeXBlLCB0aGF0
IG1lYW5zIGlnbm9yZSB0aGUgd2hvbGUgT0xSLg0KPiAgDQo+IEl0J3Mgbm90IGNsZWFyIHRvIG1l
IHdoZXRoZXIgdGhlIG9yaWdpbmFsIHRleHQgd2FzIGFib3V0IGFyYml0cmFyeSBhdnBzLCBvciBS
ZXBvcnQtVHlwZS4NCj4gIA0KPiBTdGV2ZQ0KPiAgDQo+IE9uIDEyLzkvMTQsIDExOjA0IEFNLCBX
aWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIHdyb3RlOg0KPiBIaSBTdGV2ZSwNCj4gIA0K
PiBJIHRoaW5rIGl0IHdhcyBwb2ludGVkIG91dCBieSBCZW4gdGhhdCB3ZSBkbyBub3Qgc3BlY2lm
eSBiZWhhdmlvdXIgb2YgYSBub2RlIGZvciBjYXNlcyB3aGVyZSBpdCBkZXRlY3RzIHRoYXQgYW5v
dGhlciBub2RlIGlzIGJyZWFraW5nIHRoZSBydWxlLg0KPiBUaGUgcnVsZSBpczoNCj4gICAgICBB
IHJlcG9ydGluZyBub2RlIE1VU1QgTk9UIHNlbmQgb3ZlcmxvYWQgcmVwb3J0cyBvZiBhIHR5cGUg
dGhhdCBoYXMNCj4gICAgICBub3QgYmVlbiBhZHZlcnRpc2VkIGFzIHN1cHBvcnRlZCBieSB0aGUg
cmVhY3Rpbmcgbm9kZS4NCj4gU2VlIHNlY3Rpb24gNC4yLjMuDQo+ICANCj4gUmVnYXJkcw0KPiBV
bHJpY2gNCj4gIA0KPiAgICAgRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9y
Z10gT24gQmVoYWxmIE9mIGV4dCBTdGV2ZSBEb25vdmFuDQo+IFNlbnQ6IFR1ZXNkYXksIERlY2Vt
YmVyIDA5LCAyMDE0IDI6NTIgUE0NCj4gVG86IGRpbWVAaWV0Zi5vcmcNCj4gU3ViamVjdDogW0Rp
bWVdIFVscmljaCdzIHN1Z2dlc3RlZCBjaGFuZ2UgIzE1DQo+ICANCj4gVWxyaWNoLA0KPiAgDQo+
IEZvciB5b3VyIHN1Z2dlc3RlZCBjaGFuZ2UgIzE1Og0KPiBTZWN0aW9uIDQuMi4xLjMsIDR0aCBw
YXJhZ3JhcGg6DQo+IEV4aXN0aW5nIHRleHQ6DQo+ICAgICAgV2hlbiByZWNlaXZpbmcgYW4gT0Mt
T0xSIEFWUHMgd2l0aCB1bmtub3duIHZhbHVlcywgYSByZWFjdGluZyBub2RlDQo+ICAgICAgU0hP
VUxEIGJlIHNpbGVudGx5IGRpc2NhcmRlZCBieSByZWFjdGluZyBub2RlcyBhbmQgdGhlIGV2ZW50
IFNIT1VMRA0KPiAgICAgIGJlIGxvZ2dlZC4NCj4gQ29tbWVudDogdGV4dCBpcyBjb25mdXNpbmcu
IE1heWJlIHRoZSBpbnRlbnRpb24gd2FzIHRvIHNheToNCj4gICAgICBXaGVuIHJlY2VpdmluZyBh
biBPQy1PTFIgQVZQcyB3aXRoIGFuIHVuc3VwcG9ydGVkIHJlcG9ydCB0eXBlIHZhbHVlLCBhIHJl
YWN0aW5nIG5vZGUNCj4gICAgICBTSE9VTEQgc2lsZW50bHkgZGlzY2FyZGVkIHRoZSBPQy1PTFIg
QVZQIGFuZCB0aGUgZXZlbnQgU0hPVUxEDQo+ICAgICAgYmUgbG9nZ2VkLg0KPiBCdXQgZXZlbiB0
aGF0IGlzIG5vdCBjb3JyZWN0Lg0KPiBQcm9wb3NhbDogUmVtb3ZlIHRoZSBwYXJhZ3JhcGguDQo+
IFRoZSBpbnRlbnQgd2FzIHRoYXQgYW4gT0MtT0xSIHRoYXQgY29udGFpbnMgdW5rbm93biB2YWx1
ZXMgc2hvdWxkIGJlIGRpc2NhcmRlZC4gIEkgYWdyZWUgdGhhdCB0aGUgd29yZGluZyBuZWVkcyB0
byBiZSBjaGFuZ2VzIGFzIHlvdSBzdWdnZXN0ZWQuICBJIGRvbid0IGFncmVlIHdpdGggcmVtb3Zp
bmcgdGhlIHBhcmFncmFwaC4gIENhbiB5b3UgZWxhYm9yYXRlIG9uIHdoeSB5b3UgdGhpbmsgaXQg
aXMgbm90IGNvcnJlY3Qgd2hlbiBjaGFuZ2VkIGFzIHlvdSBzdWdnZXN0ZWQ/DQo+ICANCj4gUmVn
YXJkcywNCj4gIA0KPiBTdGV2ZQ0KPiAgDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+IERpTUUgbWFpbGluZyBsaXN0DQo+IERpTUVAaWV0Zi5vcmcN
Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo+ICANCj4gIA0K
PiAgDQo+ICANCg0K


From nobody Tue Dec 23 08:40:45 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3321A0E10 for ; Tue, 23 Dec 2014 08:40:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzskiVcka3ta for ; Tue, 23 Dec 2014 08:40:41 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F7C41ACFA3 for ; Tue, 23 Dec 2014 08:40:41 -0800 (PST)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBNGedkA060130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Dec 2014 10:40:40 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681523ACF5@DEMUMBX014.nsn-intra.net>
Date: Tue, 23 Dec 2014 10:40:39 -0600
X-Mao-Original-Outgoing-Id: 441045638.876306-11faa0b53a9b76c05dc78aa981721710
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5486FE71.70205@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235215@DEMUMBX014.nsn-intra.net> <54884137.4050209@usdonovans.com> <5AB8BAC5-3CBD-432E-9631-74DF40795844@nostrum.com> <5489A498.5070203@usdonovans.com>  <5489EFAF.8010702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152358E0@DEMUMBX014.nsn-intra.net> <549046D3.3090104@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235AB9@DEMUMBX014.nsn-intra.net> <549826C8.1090809@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815239CB6@DEMUMBX014.nsn-intra.net> <1FC86658-AB09-4C11-9ED1-0C7FAFC542BE@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681523ACF5@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" 
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/U88a7JSWxXD-XsZxG4zsvA14Zl8
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #15
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Dec 2014 16:40:44 -0000

> On Dec 23, 2014, at 9:55 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:
>=20
> When the reporting node is doing things wrong, i.e. sends an OLR of a =
type that was not advertized (implicitly or explicitly), or sends two =
OLRs of same type, although the spec says "MUST NOT do so", we cannot =
expect the reacting node to sort things out.

Given the current MUST NOT, I agree. As I've mentioned in the past, we =
don't need to specify behavior on what you do when the peer violates the =
protocol. If a reacting node receives an answer with two OLRs of the =
same type, or with an OLR of a type it doesn't recognize, what it does =
is local policy. It could ignore all further DOIC information from that =
reacting node, and treat it like a non-supporting node. It could ignore =
all the OLRs in the message, but continue to exchange OC-S-Fs. It could =
process some (or one) of the OLRs and ignore the rest. It's up to the =
implementors to decide.

BTW, we don't need text to say that, unless we want to actually favor =
one strategy over another.

> I do not agree to relax the "MUST NOT do so" requirement for the =
reporting node.
>=20

I did not seriously expect us to. I just tossed it out as something to =
think about.

>=20
> -----Original Message-----
> From: ext Ben Campbell [mailto:ben@nostrum.com]=20
> Sent: Tuesday, December 23, 2014 4:06 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: ext Steve Donovan; dime@ietf.org
> Subject: Re: [Dime] Ulrich's suggested change #15
>=20
> I don't object to allowing that behavior. But thinking of a less =
extreme case, where you have two OC-OLRs and only recognize one, I think =
it would be poor design to ignore the one you do recognize. OTOH, it's =
not the IETF's job to prevent bad design, as long as it's interoperable =
and doesn't break everyone else (and the network.)
>=20
> But we might want to consider the fact that this puts the work upon =
the overloaded reporting node to make things right, rather than on the =
reacting node to figure it out. For example, the use cases I've describe =
in a separate thread, where you have multiple reacting nodes with =
different capabilities, might could be mitigated by allowing (not =
requiring) the reporting node put the OC-OLRs for both in each answer. =
We don't currently allow that unless they are different types, but I =
wonder if we should think about relaxing that.
>=20
>> On Dec 23, 2014, at 6:30 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:
>>=20
>> No, that was not what I=E2=80=99m after.
>>=20
>> Imagine the (unlikely) case where an answer message contains hundreds =
of OC-OLR AVPs.
>>=20
>> In this case I want the reacting node to be allowed
>> -          Not to scan through all the OC-OLR AVPs to see whether =
there is a supported  and not duplicated OLR
>> -          To ignore the complete set of OC-OLR AVPs if at least one =
of the OLR contains an unsupported report-type or at least two of the =
OLRs contain  the same report type.
>>=20
>> As soon as the reacting node detects that there is something wrong =
with the set of OLRs it may ignore the complete set of OLRs.
>>=20
>> Regards
>> Ulrich
>>=20
>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
>> Sent: Monday, December 22, 2014 3:12 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] Ulrich's suggested change #15
>>=20
>> I have added the following statements:
>>=20
>>   When receiving an answer message with multiple OLRs and multiple of
>>   the OLRs are of the same supported report types, a reporting node
>>   SHOULD ignore the duplicated OLRs.
>>=20
>>   A reacting node SHOULD ignore an OC-OLR with a OC-Report-Type AVP
>>   that contains an unrecognized value.
>> Regards,
>>=20
>> Steve
>>=20
>> On 12/17/14 2:49 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Yes please.
>>=20
>> -----Original Message-----
>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
>> Sent: Tuesday, December 16, 2014 3:51 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] Ulrich's suggested change #15
>>=20
>> I'll delete the paragraph.
>>=20
>> Do we need explicit statements for the two conditions below?
>>=20
>> Steve
>>=20
>>=20
>> On 12/15/14, 11:56 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Steve, Ben,
>>=20
>> I'm fine with deleting the paragraph.
>> But for my clarification please confirm that ignoring the complete =
set of OLRs is allowed when one of these OLRs contains a report type =
that was not advertized, or two of the OLRs contain the same report =
type.
>>=20
>> Regards
>> Ulrich
>>=20
>>=20
>>=20
>> -----Original Message-----
>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
>> Sent: Thursday, December 11, 2014 8:26 PM
>> To: Ben Campbell
>> Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
>> Subject: Re: [Dime] Ulrich's suggested change #15
>>=20
>>=20
>> On 12/11/14, 12:51 PM, Ben Campbell wrote:
>> On Dec 11, 2014, at 8:05 AM, Steve Donovan  =
wrote:
>>=20
>> I thought this paragraph was covering unrecognized values for all =
AVPs.
>> I agree that's what it covered. But I think we failed to cover the =
unrecognized AVP case. If we don't have anything to say beyond what 6733 =
says, then it might not be strictly necessary, but it might still be =
worth saying that "unrecognized sub-AVPs are treated as per RFC6733".
>> That is probably worth saying.
>>   Maybe it is better to remove the paragraph entirely and make sure =
that the definition of each AVP addresses what is done with unrecognized =
values.
>> Possibly. There are AVPs where there's no such thing as an =
unrecognized value. There may be AVPs where the allowed values vary by =
algorithm. If we do take that route, we probably need language here that =
says unrecognized values are handled as described by the AVP definition =
or the algorithm.
>> Agreed.
>> Steve
>>=20
>> On 12/10/14, 5:26 PM, Ben Campbell wrote:
>> On Dec 10, 2014, at 6:48 AM, Steve Donovan  =
wrote:
>>=20
>> Ulrich,
>>=20
>> Actually, the wording you suggested wasn't quite right.  It should =
be:
>>=20
>>    When receiving an OC-OLR AVP with unknown values, the overload =
report
>>    SHOULD be silently discarded by reacting nodes and the event =
SHOULD
>>    be logged.
>>=20
>> It's not just about report type values but unknown values for any of =
the AVPs in the OLR.
>>=20
>> This seems like a good requirement to include in the specification to =
ensure common behavior in reacting nodes.  I don't feel strongly about =
this but I would like to hear other opinions.
>> I think this is still not quite complete.
>>=20
>> If you receive a sub-AVP that you don't understand, then you should =
ignore that sub-avp, not the whole OC-OLR AVP.  (Unless of course the =
unknown AVP has the m-bit set.) If you receive a known sub-AVP, with a =
value you don't understand, the behavior should be AVP specific. For =
Report-Type, that means ignore the whole OLR.
>>=20
>> It's not clear to me whether the original text was about arbitrary =
avps, or Report-Type.
>>=20
>> Steve
>>=20
>> On 12/9/14, 11:04 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Hi Steve,
>>=20
>> I think it was pointed out by Ben that we do not specify behaviour of =
a node for cases where it detects that another node is breaking the =
rule.
>> The rule is:
>>     A reporting node MUST NOT send overload reports of a type that =
has
>>     not been advertised as supported by the reacting node.
>> See section 4.2.3.
>>=20
>> Regards
>> Ulrich
>>=20
>>    From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve =
Donovan
>> Sent: Tuesday, December 09, 2014 2:52 PM
>> To: dime@ietf.org
>> Subject: [Dime] Ulrich's suggested change #15
>>=20
>> Ulrich,
>>=20
>> For your suggested change #15:
>> Section 4.2.1.3, 4th paragraph:
>> Existing text:
>>     When receiving an OC-OLR AVPs with unknown values, a reacting =
node
>>     SHOULD be silently discarded by reacting nodes and the event =
SHOULD
>>     be logged.
>> Comment: text is confusing. Maybe the intention was to say:
>>     When receiving an OC-OLR AVPs with an unsupported report type =
value, a reacting node
>>     SHOULD silently discarded the OC-OLR AVP and the event SHOULD
>>     be logged.
>> But even that is not correct.
>> Proposal: Remove the paragraph.
>> The intent was that an OC-OLR that contains unknown values should be =
discarded.  I agree that the wording needs to be changes as you =
suggested.  I don't agree with removing the paragraph.  Can you =
elaborate on why you think it is not correct when changed as you =
suggested?
>>=20
>> Regards,
>>=20
>> Steve
>>=20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>>=20
>>=20
>>=20
>=20


From nobody Tue Dec 23 08:54:49 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F741A09C9 for ; Tue, 23 Dec 2014 08:54:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqgvbgWPQGdV for ; Tue, 23 Dec 2014 08:54:30 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC8591A1A74 for ; Tue, 23 Dec 2014 08:54:23 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBNGsLXu004745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Dec 2014 16:54:21 GMT
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBNGsLCD022246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Dec 2014 17:54:21 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.60]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0195.001; Tue, 23 Dec 2014 17:54:20 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Ben Campbell 
Thread-Topic: [Dime] Ulrich's suggested change #15
Thread-Index: AQHQE7dJhQB5e1nbwEev114RSsJu35yHeSWggAL2Z7uAAD8mAIAACZWAgAY/jwCAAU9ggIABPegggAglTQCAAYF28IAAH80AgAAaZ9CAAAAWgIAAFGEA
Date: Tue, 23 Dec 2014 16:54:19 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681523AD21@DEMUMBX014.nsn-intra.net>
References: <5486FE71.70205@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235215@DEMUMBX014.nsn-intra.net> <54884137.4050209@usdonovans.com> <5AB8BAC5-3CBD-432E-9631-74DF40795844@nostrum.com> <5489A498.5070203@usdonovans.com>  <5489EFAF.8010702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152358E0@DEMUMBX014.nsn-intra.net> <549046D3.3090104@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235AB9@DEMUMBX014.nsn-intra.net> <549826C8.1090809@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815239CB6@DEMUMBX014.nsn-intra.net> <1FC86658-AB09-4C11-9ED1-0C7FAFC542BE@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681523ACF5@DEMUMBX014.nsn-intra.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.111]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 12472
X-purgate-ID: 151667::1419353661-00002DC5-FB468725/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/BSBFL5mnWRl_QBRlO6RowKGtByk
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #15
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Dec 2014 16:54:38 -0000

VGhhbmsgeW91IGZvciB0aGUgY2xhcmlmaWNhdGlvbi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCkZyb206IGV4dCBCZW4gQ2FtcGJlbGwgW21haWx0bzpiZW5Abm9zdHJ1bS5jb21dIA0K
U2VudDogVHVlc2RheSwgRGVjZW1iZXIgMjMsIDIwMTQgNTo0MSBQTQ0KVG86IFdpZWhlLCBVbHJp
Y2ggKE5TTiAtIERFL011bmljaCkNCkNjOiBleHQgU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9y
Zw0KU3ViamVjdDogUmU6IFtEaW1lXSBVbHJpY2gncyBzdWdnZXN0ZWQgY2hhbmdlICMxNQ0KDQoN
Cj4gT24gRGVjIDIzLCAyMDE0LCBhdCA5OjU1IEFNLCBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9N
dW5pY2gpIDx1bHJpY2gud2llaGVAbnNuLmNvbT4gd3JvdGU6DQo+IA0KPiBXaGVuIHRoZSByZXBv
cnRpbmcgbm9kZSBpcyBkb2luZyB0aGluZ3Mgd3JvbmcsIGkuZS4gc2VuZHMgYW4gT0xSIG9mIGEg
dHlwZSB0aGF0IHdhcyBub3QgYWR2ZXJ0aXplZCAoaW1wbGljaXRseSBvciBleHBsaWNpdGx5KSwg
b3Igc2VuZHMgdHdvIE9MUnMgb2Ygc2FtZSB0eXBlLCBhbHRob3VnaCB0aGUgc3BlYyBzYXlzICJN
VVNUIE5PVCBkbyBzbyIsIHdlIGNhbm5vdCBleHBlY3QgdGhlIHJlYWN0aW5nIG5vZGUgdG8gc29y
dCB0aGluZ3Mgb3V0Lg0KDQpHaXZlbiB0aGUgY3VycmVudCBNVVNUIE5PVCwgSSBhZ3JlZS4gQXMg
SSd2ZSBtZW50aW9uZWQgaW4gdGhlIHBhc3QsIHdlIGRvbid0IG5lZWQgdG8gc3BlY2lmeSBiZWhh
dmlvciBvbiB3aGF0IHlvdSBkbyB3aGVuIHRoZSBwZWVyIHZpb2xhdGVzIHRoZSBwcm90b2NvbC4g
SWYgYSByZWFjdGluZyBub2RlIHJlY2VpdmVzIGFuIGFuc3dlciB3aXRoIHR3byBPTFJzIG9mIHRo
ZSBzYW1lIHR5cGUsIG9yIHdpdGggYW4gT0xSIG9mIGEgdHlwZSBpdCBkb2Vzbid0IHJlY29nbml6
ZSwgd2hhdCBpdCBkb2VzIGlzIGxvY2FsIHBvbGljeS4gSXQgY291bGQgaWdub3JlIGFsbCBmdXJ0
aGVyIERPSUMgaW5mb3JtYXRpb24gZnJvbSB0aGF0IHJlYWN0aW5nIG5vZGUsIGFuZCB0cmVhdCBp
dCBsaWtlIGEgbm9uLXN1cHBvcnRpbmcgbm9kZS4gSXQgY291bGQgaWdub3JlIGFsbCB0aGUgT0xS
cyBpbiB0aGUgbWVzc2FnZSwgYnV0IGNvbnRpbnVlIHRvIGV4Y2hhbmdlIE9DLVMtRnMuIEl0IGNv
dWxkIHByb2Nlc3Mgc29tZSAob3Igb25lKSBvZiB0aGUgT0xScyBhbmQgaWdub3JlIHRoZSByZXN0
LiBJdCdzIHVwIHRvIHRoZSBpbXBsZW1lbnRvcnMgdG8gZGVjaWRlLg0KDQpCVFcsIHdlIGRvbid0
IG5lZWQgdGV4dCB0byBzYXkgdGhhdCwgdW5sZXNzIHdlIHdhbnQgdG8gYWN0dWFsbHkgZmF2b3Ig
b25lIHN0cmF0ZWd5IG92ZXIgYW5vdGhlci4NCg0KPiBJIGRvIG5vdCBhZ3JlZSB0byByZWxheCB0
aGUgIk1VU1QgTk9UIGRvIHNvIiByZXF1aXJlbWVudCBmb3IgdGhlIHJlcG9ydGluZyBub2RlLg0K
PiANCg0KSSBkaWQgbm90IHNlcmlvdXNseSBleHBlY3QgdXMgdG8uIEkganVzdCB0b3NzZWQgaXQg
b3V0IGFzIHNvbWV0aGluZyB0byB0aGluayBhYm91dC4NCg0KPiANCj4gLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCj4gRnJvbTogZXh0IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJlbkBub3N0cnVt
LmNvbV0gDQo+IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDIzLCAyMDE0IDQ6MDYgUE0NCj4gVG86
IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkNCj4gQ2M6IGV4dCBTdGV2ZSBEb25vdmFu
OyBkaW1lQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbRGltZV0gVWxyaWNoJ3Mgc3VnZ2VzdGVk
IGNoYW5nZSAjMTUNCj4gDQo+IEkgZG9uJ3Qgb2JqZWN0IHRvIGFsbG93aW5nIHRoYXQgYmVoYXZp
b3IuIEJ1dCB0aGlua2luZyBvZiBhIGxlc3MgZXh0cmVtZSBjYXNlLCB3aGVyZSB5b3UgaGF2ZSB0
d28gT0MtT0xScyBhbmQgb25seSByZWNvZ25pemUgb25lLCBJIHRoaW5rIGl0IHdvdWxkIGJlIHBv
b3IgZGVzaWduIHRvIGlnbm9yZSB0aGUgb25lIHlvdSBkbyByZWNvZ25pemUuIE9UT0gsIGl0J3Mg
bm90IHRoZSBJRVRGJ3Mgam9iIHRvIHByZXZlbnQgYmFkIGRlc2lnbiwgYXMgbG9uZyBhcyBpdCdz
IGludGVyb3BlcmFibGUgYW5kIGRvZXNuJ3QgYnJlYWsgZXZlcnlvbmUgZWxzZSAoYW5kIHRoZSBu
ZXR3b3JrLikNCj4gDQo+IEJ1dCB3ZSBtaWdodCB3YW50IHRvIGNvbnNpZGVyIHRoZSBmYWN0IHRo
YXQgdGhpcyBwdXRzIHRoZSB3b3JrIHVwb24gdGhlIG92ZXJsb2FkZWQgcmVwb3J0aW5nIG5vZGUg
dG8gbWFrZSB0aGluZ3MgcmlnaHQsIHJhdGhlciB0aGFuIG9uIHRoZSByZWFjdGluZyBub2RlIHRv
IGZpZ3VyZSBpdCBvdXQuIEZvciBleGFtcGxlLCB0aGUgdXNlIGNhc2VzIEkndmUgZGVzY3JpYmUg
aW4gYSBzZXBhcmF0ZSB0aHJlYWQsIHdoZXJlIHlvdSBoYXZlIG11bHRpcGxlIHJlYWN0aW5nIG5v
ZGVzIHdpdGggZGlmZmVyZW50IGNhcGFiaWxpdGllcywgbWlnaHQgY291bGQgYmUgbWl0aWdhdGVk
IGJ5IGFsbG93aW5nIChub3QgcmVxdWlyaW5nKSB0aGUgcmVwb3J0aW5nIG5vZGUgcHV0IHRoZSBP
Qy1PTFJzIGZvciBib3RoIGluIGVhY2ggYW5zd2VyLiBXZSBkb24ndCBjdXJyZW50bHkgYWxsb3cg
dGhhdCB1bmxlc3MgdGhleSBhcmUgZGlmZmVyZW50IHR5cGVzLCBidXQgSSB3b25kZXIgaWYgd2Ug
c2hvdWxkIHRoaW5rIGFib3V0IHJlbGF4aW5nIHRoYXQuDQo+IA0KPj4gT24gRGVjIDIzLCAyMDE0
LCBhdCA2OjMwIEFNLCBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIDx1bHJpY2gud2ll
aGVAbnNuLmNvbT4gd3JvdGU6DQo+PiANCj4+IE5vLCB0aGF0IHdhcyBub3Qgd2hhdCBJ4oCZbSBh
ZnRlci4NCj4+IA0KPj4gSW1hZ2luZSB0aGUgKHVubGlrZWx5KSBjYXNlIHdoZXJlIGFuIGFuc3dl
ciBtZXNzYWdlIGNvbnRhaW5zIGh1bmRyZWRzIG9mIE9DLU9MUiBBVlBzLg0KPj4gDQo+PiBJbiB0
aGlzIGNhc2UgSSB3YW50IHRoZSByZWFjdGluZyBub2RlIHRvIGJlIGFsbG93ZWQNCj4+IC0gICAg
ICAgICAgTm90IHRvIHNjYW4gdGhyb3VnaCBhbGwgdGhlIE9DLU9MUiBBVlBzIHRvIHNlZSB3aGV0
aGVyIHRoZXJlIGlzIGEgc3VwcG9ydGVkICBhbmQgbm90IGR1cGxpY2F0ZWQgT0xSDQo+PiAtICAg
ICAgICAgIFRvIGlnbm9yZSB0aGUgY29tcGxldGUgc2V0IG9mIE9DLU9MUiBBVlBzIGlmIGF0IGxl
YXN0IG9uZSBvZiB0aGUgT0xSIGNvbnRhaW5zIGFuIHVuc3VwcG9ydGVkIHJlcG9ydC10eXBlIG9y
IGF0IGxlYXN0IHR3byBvZiB0aGUgT0xScyBjb250YWluICB0aGUgc2FtZSByZXBvcnQgdHlwZS4N
Cj4+IA0KPj4gQXMgc29vbiBhcyB0aGUgcmVhY3Rpbmcgbm9kZSBkZXRlY3RzIHRoYXQgdGhlcmUg
aXMgc29tZXRoaW5nIHdyb25nIHdpdGggdGhlIHNldCBvZiBPTFJzIGl0IG1heSBpZ25vcmUgdGhl
IGNvbXBsZXRlIHNldCBvZiBPTFJzLg0KPj4gDQo+PiBSZWdhcmRzDQo+PiBVbHJpY2gNCj4+IA0K
Pj4gRnJvbTogZXh0IFN0ZXZlIERvbm92YW4gW21haWx0bzpzcmRvbm92YW5AdXNkb25vdmFucy5j
b21dIA0KPj4gU2VudDogTW9uZGF5LCBEZWNlbWJlciAyMiwgMjAxNCAzOjEyIFBNDQo+PiBUbzog
V2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsgQmVuIENhbXBiZWxsDQo+PiBDYzogZGlt
ZUBpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtEaW1lXSBVbHJpY2gncyBzdWdnZXN0ZWQgY2hh
bmdlICMxNQ0KPj4gDQo+PiBJIGhhdmUgYWRkZWQgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnRzOg0K
Pj4gDQo+PiAgIFdoZW4gcmVjZWl2aW5nIGFuIGFuc3dlciBtZXNzYWdlIHdpdGggbXVsdGlwbGUg
T0xScyBhbmQgbXVsdGlwbGUgb2YNCj4+ICAgdGhlIE9MUnMgYXJlIG9mIHRoZSBzYW1lIHN1cHBv
cnRlZCByZXBvcnQgdHlwZXMsIGEgcmVwb3J0aW5nIG5vZGUNCj4+ICAgU0hPVUxEIGlnbm9yZSB0
aGUgZHVwbGljYXRlZCBPTFJzLg0KPj4gDQo+PiAgIEEgcmVhY3Rpbmcgbm9kZSBTSE9VTEQgaWdu
b3JlIGFuIE9DLU9MUiB3aXRoIGEgT0MtUmVwb3J0LVR5cGUgQVZQDQo+PiAgIHRoYXQgY29udGFp
bnMgYW4gdW5yZWNvZ25pemVkIHZhbHVlLg0KPj4gUmVnYXJkcywNCj4+IA0KPj4gU3RldmUNCj4+
IA0KPj4gT24gMTIvMTcvMTQgMjo0OSBBTSwgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNo
KSB3cm90ZToNCj4+IFllcyBwbGVhc2UuDQo+PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQo+PiBGcm9tOiBleHQgU3RldmUgRG9ub3ZhbiBbbWFpbHRvOnNyZG9ub3ZhbkB1c2Rvbm92
YW5zLmNvbV0gDQo+PiBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAxNiwgMjAxNCAzOjUxIFBNDQo+
PiBUbzogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsgQmVuIENhbXBiZWxsDQo+PiBD
YzogZGltZUBpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtEaW1lXSBVbHJpY2gncyBzdWdnZXN0
ZWQgY2hhbmdlICMxNQ0KPj4gDQo+PiBJJ2xsIGRlbGV0ZSB0aGUgcGFyYWdyYXBoLg0KPj4gDQo+
PiBEbyB3ZSBuZWVkIGV4cGxpY2l0IHN0YXRlbWVudHMgZm9yIHRoZSB0d28gY29uZGl0aW9ucyBi
ZWxvdz8NCj4+IA0KPj4gU3RldmUNCj4+IA0KPj4gDQo+PiBPbiAxMi8xNS8xNCwgMTE6NTYgQU0s
IFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgd3JvdGU6DQo+PiBTdGV2ZSwgQmVuLA0K
Pj4gDQo+PiBJJ20gZmluZSB3aXRoIGRlbGV0aW5nIHRoZSBwYXJhZ3JhcGguDQo+PiBCdXQgZm9y
IG15IGNsYXJpZmljYXRpb24gcGxlYXNlIGNvbmZpcm0gdGhhdCBpZ25vcmluZyB0aGUgY29tcGxl
dGUgc2V0IG9mIE9MUnMgaXMgYWxsb3dlZCB3aGVuIG9uZSBvZiB0aGVzZSBPTFJzIGNvbnRhaW5z
IGEgcmVwb3J0IHR5cGUgdGhhdCB3YXMgbm90IGFkdmVydGl6ZWQsIG9yIHR3byBvZiB0aGUgT0xS
cyBjb250YWluIHRoZSBzYW1lIHJlcG9ydCB0eXBlLg0KPj4gDQo+PiBSZWdhcmRzDQo+PiBVbHJp
Y2gNCj4+IA0KPj4gDQo+PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9t
OiBleHQgU3RldmUgRG9ub3ZhbiBbbWFpbHRvOnNyZG9ub3ZhbkB1c2Rvbm92YW5zLmNvbV0NCj4+
IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAxMSwgMjAxNCA4OjI2IFBNDQo+PiBUbzogQmVuIENh
bXBiZWxsDQo+PiBDYzogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKTsgZGltZUBpZXRm
Lm9yZw0KPj4gU3ViamVjdDogUmU6IFtEaW1lXSBVbHJpY2gncyBzdWdnZXN0ZWQgY2hhbmdlICMx
NQ0KPj4gDQo+PiANCj4+IE9uIDEyLzExLzE0LCAxMjo1MSBQTSwgQmVuIENhbXBiZWxsIHdyb3Rl
Og0KPj4gT24gRGVjIDExLCAyMDE0LCBhdCA4OjA1IEFNLCBTdGV2ZSBEb25vdmFuIDxzcmRvbm92
YW5AdXNkb25vdmFucy5jb20+IHdyb3RlOg0KPj4gDQo+PiBJIHRob3VnaHQgdGhpcyBwYXJhZ3Jh
cGggd2FzIGNvdmVyaW5nIHVucmVjb2duaXplZCB2YWx1ZXMgZm9yIGFsbCBBVlBzLg0KPj4gSSBh
Z3JlZSB0aGF0J3Mgd2hhdCBpdCBjb3ZlcmVkLiBCdXQgSSB0aGluayB3ZSBmYWlsZWQgdG8gY292
ZXIgdGhlIHVucmVjb2duaXplZCBBVlAgY2FzZS4gSWYgd2UgZG9uJ3QgaGF2ZSBhbnl0aGluZyB0
byBzYXkgYmV5b25kIHdoYXQgNjczMyBzYXlzLCB0aGVuIGl0IG1pZ2h0IG5vdCBiZSBzdHJpY3Rs
eSBuZWNlc3NhcnksIGJ1dCBpdCBtaWdodCBzdGlsbCBiZSB3b3J0aCBzYXlpbmcgdGhhdCAidW5y
ZWNvZ25pemVkIHN1Yi1BVlBzIGFyZSB0cmVhdGVkIGFzIHBlciBSRkM2NzMzIi4NCj4+IFRoYXQg
aXMgcHJvYmFibHkgd29ydGggc2F5aW5nLg0KPj4gICBNYXliZSBpdCBpcyBiZXR0ZXIgdG8gcmVt
b3ZlIHRoZSBwYXJhZ3JhcGggZW50aXJlbHkgYW5kIG1ha2Ugc3VyZSB0aGF0IHRoZSBkZWZpbml0
aW9uIG9mIGVhY2ggQVZQIGFkZHJlc3NlcyB3aGF0IGlzIGRvbmUgd2l0aCB1bnJlY29nbml6ZWQg
dmFsdWVzLg0KPj4gUG9zc2libHkuIFRoZXJlIGFyZSBBVlBzIHdoZXJlIHRoZXJlJ3Mgbm8gc3Vj
aCB0aGluZyBhcyBhbiB1bnJlY29nbml6ZWQgdmFsdWUuIFRoZXJlIG1heSBiZSBBVlBzIHdoZXJl
IHRoZSBhbGxvd2VkIHZhbHVlcyB2YXJ5IGJ5IGFsZ29yaXRobS4gSWYgd2UgZG8gdGFrZSB0aGF0
IHJvdXRlLCB3ZSBwcm9iYWJseSBuZWVkIGxhbmd1YWdlIGhlcmUgdGhhdCBzYXlzIHVucmVjb2du
aXplZCB2YWx1ZXMgYXJlIGhhbmRsZWQgYXMgZGVzY3JpYmVkIGJ5IHRoZSBBVlAgZGVmaW5pdGlv
biBvciB0aGUgYWxnb3JpdGhtLg0KPj4gQWdyZWVkLg0KPj4gU3RldmUNCj4+IA0KPj4gT24gMTIv
MTAvMTQsIDU6MjYgUE0sIEJlbiBDYW1wYmVsbCB3cm90ZToNCj4+IE9uIERlYyAxMCwgMjAxNCwg
YXQgNjo0OCBBTSwgU3RldmUgRG9ub3ZhbiA8c3Jkb25vdmFuQHVzZG9ub3ZhbnMuY29tPiB3cm90
ZToNCj4+IA0KPj4gVWxyaWNoLA0KPj4gDQo+PiBBY3R1YWxseSwgdGhlIHdvcmRpbmcgeW91IHN1
Z2dlc3RlZCB3YXNuJ3QgcXVpdGUgcmlnaHQuICBJdCBzaG91bGQgYmU6DQo+PiANCj4+ICAgIFdo
ZW4gcmVjZWl2aW5nIGFuIE9DLU9MUiBBVlAgd2l0aCB1bmtub3duIHZhbHVlcywgdGhlIG92ZXJs
b2FkIHJlcG9ydA0KPj4gICAgU0hPVUxEIGJlIHNpbGVudGx5IGRpc2NhcmRlZCBieSByZWFjdGlu
ZyBub2RlcyBhbmQgdGhlIGV2ZW50IFNIT1VMRA0KPj4gICAgYmUgbG9nZ2VkLg0KPj4gDQo+PiBJ
dCdzIG5vdCBqdXN0IGFib3V0IHJlcG9ydCB0eXBlIHZhbHVlcyBidXQgdW5rbm93biB2YWx1ZXMg
Zm9yIGFueSBvZiB0aGUgQVZQcyBpbiB0aGUgT0xSLg0KPj4gDQo+PiBUaGlzIHNlZW1zIGxpa2Ug
YSBnb29kIHJlcXVpcmVtZW50IHRvIGluY2x1ZGUgaW4gdGhlIHNwZWNpZmljYXRpb24gdG8gZW5z
dXJlIGNvbW1vbiBiZWhhdmlvciBpbiByZWFjdGluZyBub2Rlcy4gIEkgZG9uJ3QgZmVlbCBzdHJv
bmdseSBhYm91dCB0aGlzIGJ1dCBJIHdvdWxkIGxpa2UgdG8gaGVhciBvdGhlciBvcGluaW9ucy4N
Cj4+IEkgdGhpbmsgdGhpcyBpcyBzdGlsbCBub3QgcXVpdGUgY29tcGxldGUuDQo+PiANCj4+IElm
IHlvdSByZWNlaXZlIGEgc3ViLUFWUCB0aGF0IHlvdSBkb24ndCB1bmRlcnN0YW5kLCB0aGVuIHlv
dSBzaG91bGQgaWdub3JlIHRoYXQgc3ViLWF2cCwgbm90IHRoZSB3aG9sZSBPQy1PTFIgQVZQLiAg
KFVubGVzcyBvZiBjb3Vyc2UgdGhlIHVua25vd24gQVZQIGhhcyB0aGUgbS1iaXQgc2V0LikgSWYg
eW91IHJlY2VpdmUgYSBrbm93biBzdWItQVZQLCB3aXRoIGEgdmFsdWUgeW91IGRvbid0IHVuZGVy
c3RhbmQsIHRoZSBiZWhhdmlvciBzaG91bGQgYmUgQVZQIHNwZWNpZmljLiBGb3IgUmVwb3J0LVR5
cGUsIHRoYXQgbWVhbnMgaWdub3JlIHRoZSB3aG9sZSBPTFIuDQo+PiANCj4+IEl0J3Mgbm90IGNs
ZWFyIHRvIG1lIHdoZXRoZXIgdGhlIG9yaWdpbmFsIHRleHQgd2FzIGFib3V0IGFyYml0cmFyeSBh
dnBzLCBvciBSZXBvcnQtVHlwZS4NCj4+IA0KPj4gU3RldmUNCj4+IA0KPj4gT24gMTIvOS8xNCwg
MTE6MDQgQU0sIFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgd3JvdGU6DQo+PiBIaSBT
dGV2ZSwNCj4+IA0KPj4gSSB0aGluayBpdCB3YXMgcG9pbnRlZCBvdXQgYnkgQmVuIHRoYXQgd2Ug
ZG8gbm90IHNwZWNpZnkgYmVoYXZpb3VyIG9mIGEgbm9kZSBmb3IgY2FzZXMgd2hlcmUgaXQgZGV0
ZWN0cyB0aGF0IGFub3RoZXIgbm9kZSBpcyBicmVha2luZyB0aGUgcnVsZS4NCj4+IFRoZSBydWxl
IGlzOg0KPj4gICAgIEEgcmVwb3J0aW5nIG5vZGUgTVVTVCBOT1Qgc2VuZCBvdmVybG9hZCByZXBv
cnRzIG9mIGEgdHlwZSB0aGF0IGhhcw0KPj4gICAgIG5vdCBiZWVuIGFkdmVydGlzZWQgYXMgc3Vw
cG9ydGVkIGJ5IHRoZSByZWFjdGluZyBub2RlLg0KPj4gU2VlIHNlY3Rpb24gNC4yLjMuDQo+PiAN
Cj4+IFJlZ2FyZHMNCj4+IFVscmljaA0KPj4gDQo+PiAgICBGcm9tOiBEaU1FIFttYWlsdG86ZGlt
ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IFN0ZXZlIERvbm92YW4NCj4+IFNl
bnQ6IFR1ZXNkYXksIERlY2VtYmVyIDA5LCAyMDE0IDI6NTIgUE0NCj4+IFRvOiBkaW1lQGlldGYu
b3JnDQo+PiBTdWJqZWN0OiBbRGltZV0gVWxyaWNoJ3Mgc3VnZ2VzdGVkIGNoYW5nZSAjMTUNCj4+
IA0KPj4gVWxyaWNoLA0KPj4gDQo+PiBGb3IgeW91ciBzdWdnZXN0ZWQgY2hhbmdlICMxNToNCj4+
IFNlY3Rpb24gNC4yLjEuMywgNHRoIHBhcmFncmFwaDoNCj4+IEV4aXN0aW5nIHRleHQ6DQo+PiAg
ICAgV2hlbiByZWNlaXZpbmcgYW4gT0MtT0xSIEFWUHMgd2l0aCB1bmtub3duIHZhbHVlcywgYSBy
ZWFjdGluZyBub2RlDQo+PiAgICAgU0hPVUxEIGJlIHNpbGVudGx5IGRpc2NhcmRlZCBieSByZWFj
dGluZyBub2RlcyBhbmQgdGhlIGV2ZW50IFNIT1VMRA0KPj4gICAgIGJlIGxvZ2dlZC4NCj4+IENv
bW1lbnQ6IHRleHQgaXMgY29uZnVzaW5nLiBNYXliZSB0aGUgaW50ZW50aW9uIHdhcyB0byBzYXk6
DQo+PiAgICAgV2hlbiByZWNlaXZpbmcgYW4gT0MtT0xSIEFWUHMgd2l0aCBhbiB1bnN1cHBvcnRl
ZCByZXBvcnQgdHlwZSB2YWx1ZSwgYSByZWFjdGluZyBub2RlDQo+PiAgICAgU0hPVUxEIHNpbGVu
dGx5IGRpc2NhcmRlZCB0aGUgT0MtT0xSIEFWUCBhbmQgdGhlIGV2ZW50IFNIT1VMRA0KPj4gICAg
IGJlIGxvZ2dlZC4NCj4+IEJ1dCBldmVuIHRoYXQgaXMgbm90IGNvcnJlY3QuDQo+PiBQcm9wb3Nh
bDogUmVtb3ZlIHRoZSBwYXJhZ3JhcGguDQo+PiBUaGUgaW50ZW50IHdhcyB0aGF0IGFuIE9DLU9M
UiB0aGF0IGNvbnRhaW5zIHVua25vd24gdmFsdWVzIHNob3VsZCBiZSBkaXNjYXJkZWQuICBJIGFn
cmVlIHRoYXQgdGhlIHdvcmRpbmcgbmVlZHMgdG8gYmUgY2hhbmdlcyBhcyB5b3Ugc3VnZ2VzdGVk
LiAgSSBkb24ndCBhZ3JlZSB3aXRoIHJlbW92aW5nIHRoZSBwYXJhZ3JhcGguICBDYW4geW91IGVs
YWJvcmF0ZSBvbiB3aHkgeW91IHRoaW5rIGl0IGlzIG5vdCBjb3JyZWN0IHdoZW4gY2hhbmdlZCBh
cyB5b3Ugc3VnZ2VzdGVkPw0KPj4gDQo+PiBSZWdhcmRzLA0KPj4gDQo+PiBTdGV2ZQ0KPj4gDQo+
PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gRGlN
RSBtYWlsaW5nIGxpc3QNCj4+IERpTUVAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vZGltZQ0KPj4gDQo+PiANCj4+IA0KPj4gDQo+IA0KDQo=


From nobody Tue Dec 23 08:57:36 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B181ACFE1 for ; Tue, 23 Dec 2014 08:57:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nb0Ve7sy1Z59 for ; Tue, 23 Dec 2014 08:57:28 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92DC71ACFE3 for ; Tue, 23 Dec 2014 08:57:27 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBNGvPnF010361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Dec 2014 16:57:25 GMT
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBNGvO6A026212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Dec 2014 17:57:25 +0100
Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 23 Dec 2014 17:57:23 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.60]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0195.001; Tue, 23 Dec 2014 17:57:24 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Ben Campbell 
Thread-Topic: [Dime] DOIC WGLC: Changing Algorithms
Thread-Index: AQHQGbTAD7bF1y5nZ0Ktqi3JfsBjdJyTTUsAgAB56ICAACGtgIAAEAyAgAAEZQCAAA7IgIAABxKAgAAra4CAAAU7AIAACEAAgAAEPQCAAU0+QIABqogAgAYWTfA=
Date: Tue, 23 Dec 2014 16:57:23 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681523AD33@DEMUMBX014.nsn-intra.net>
References:  <54912CBA.8080701@gmail.com> <549192FD.7060403@usdonovans.com>  <5491BCB3.30608@usdonovans.com> <0EEB7B88-CEEF-4A33-BD61-E4378F0D054D@nostrum.com> <5491CCC9.3090809@usdonovans.com> <4586B22E-3CDD-462E-8246-D55F25F4365C@nostrum.com> <5491F723.6080203@usdonovans.com>  <54920272.80508@usdonovans.com> <52901958-73B6-49FE-8DA4-A8D2F8276DD0@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D900066815235CCD@DEMUMBX014.nsn-intra.net> <8FB9C2A7-7D61-4D46-9808-AD17DB61B8CE@nostrum.com>
In-Reply-To: <8FB9C2A7-7D61-4D46-9808-AD17DB61B8CE@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.111]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 15042
X-purgate-ID: 151667::1419353845-00002DC5-55EE498B/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/oKjo6UUJrxagmfFCPYH6KzdPh4s
Cc: "dime@ietf.org" 
Subject: Re: [Dime] DOIC WGLC: Changing Algorithms
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Dec 2014 16:57:32 -0000

Ben, Steve,
I do not agree.

Assume the following example:
A reporting node S supports 3 algorithms: Loss, AlgoA, and AlgoB.
For a given reacting node C this results in 4 possible cases of commonly su=
pported algorithms:
Case a) only Loss is commonly supported by S and C
Case b) Loss and AlgoA are the only commonly supported algorithms by S an C=
,
Case c) Loss and AlgoB are the only commonly supported algorithms by S and =
C,
Case d) Loss, AlgoA, and AlgoB are the only commonly supported algorithms b=
y S and C.

Now S may be configured to select Loss in case a), AlgoA in case b), AlgoB =
in case c), and AlgoA in case d).
(Actually a modification of this configuration is regarded a change of algo=
rithm and must not be done while in an overload condition)

When entering an overload condition, S has to create and maintain 3 OCSs, o=
ne for Loss, one for AlgoA, and one for AlgoB.

When receiving a request from a reacting node Ca (case a)), S returns the O=
LR that corresponds to the Loss OCS.
When receiving a request from a reacting node Cb (case b)), S returns the O=
LR that corresponds to the AlgoA OCS.
When receiving a request from a reacting node Cc (case c)), S returns the O=
LR that corresponds to the AlgoB OCS.
When receiving a request from a reacting node Cd (case d)), S returns the O=
LR that corresponds to the AlgoA OCS.

Let's focus on reacting node Cc. It advertizes Loss and AlgoB (and possibly=
 additional algorithms that are not supported by S). Assume this reacting n=
ode now also supports AlgoA. Why would the reacting node not be allowed to =
immediately return the OLR that corresponds to the AlgoA OCS?
Keeping sending of OLRs that correspond to the AlgoB OSC would require the =
reporting node to keep state. (the actual case is case d) (as can be determ=
ined from the received request) while the case when the first request from =
Cc was received after entering the overload condition was case c) (can only=
 be determined from a stored state).

In summary: the reporting node should be allowed to change algorithm simply=
 because the reacting node advertises other algorithms in addition to one c=
urrently in use.

Now let's focus on node Cb. It advertizes Loss and AlgoA. Why would it not =
be allowed for Cb to stopp advertizing AlgoA? S would immediately return th=
e OLR that corresponds to the Loss OCS. S would not even be required to be =
aware of the change. S just bases its action on the content of the received=
 request, no need to maintain a node-specific state.

In summary the reporting node is allowed to change the set of advertized al=
gorithms at any time, as long as it is prepared to accept the consequences.

The real requirement for not changing algorithm during overload is for the =
reporting node: The reporting node MUST NOT change the selected algorithm w=
hile the reacting node did not change the set of advertized algorithms.

This requirement can be met without keeping reacting-node-specific state.

Ulrich



-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com]=20
Sent: Friday, December 19, 2014 8:58 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: Steve Donovan; dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: Changing Algorithms

Steve and I had an offline discussion, and I think we agree that the report=
ing node can be forced to change algorithms during an active overload condi=
tion, if it gets a request that doesn't advertise support for the active al=
gorithm.

We currently have text forbidding the reporting node from changing algorith=
ms during an active overload condition, without making this exception. We a=
ssume that we still want to otherwise keep the limitation on algorithm chan=
ges during overload. Here's a concrete proposal:

In 4.1.2:

Old:

For an ongoing overload condition, a reporting node MUST NOT change the sel=
ected algorithm during the period of time that it is in an overload conditi=
on and, as a result, is sending OC-OLR AVPs in answer messages.

New:

For an ongoing overload condition, a reporting node MUST NOT initiate a cha=
nge to the selected algorithm during the period of time that it is in an ov=
erload condition and, as a result, is sending OC-OLR AVPs in answer message=
s. This rule does not affect the case where the OC-Supported-Features in a =
new request matching the OLR does not advertise support for the current alg=
orithm, in which case the reporting node would be forced to change algorith=
ms. However, this rule does constrain the reporting node from changing algo=
rithms simply because the reacting node advertises other algorithms in addi=
tion to one currently in use.

Added text in 4.1.1:

If a reacting node is using an abatement algorithm to abate traffic due to =
an active OLR from a reporting node, the reacting node SHOULD continue to a=
dvertise support for that algorithm in future requests that match the OLR, =
until the overload condition is terminated.


> On Dec 18, 2014, at 11:46 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:
>=20
> Ben, Steve,
>=20
> Section 4.2.1.2 says:
>   A reporting node SHOULD maintain OCS entries per supported Diameter
>   application, per supported (and eventually selected) Abatement
>   Algorithm and per report-type.
>=20
> For example, an HSS would maintain two OCSs for S6a host-type reports, on=
e for loss and one for rate. When receiving a request that advertises only =
loss, the returned OLR would be the one according to the loss-OCS; When rec=
eiving a request that advertises loss and rate, the HSS has two returned OL=
R would be the one according to the rate-OCS.
>=20
> I don't see a problem when algorithm is changed at the reacting node.
>=20
> Ulrich
>=20
>=20
>=20
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
> Sent: Wednesday, December 17, 2014 11:39 PM
> To: Steve Donovan
> Cc: dime@ietf.org
> Subject: Re: [Dime] DOIC WGLC: Changing Algorithms
>=20
>=20
>> On Dec 17, 2014, at 4:23 PM, Steve Donovan  wr=
ote:
>>=20
>>=20
>> On 12/17/14 3:54 PM, Ben Campbell wrote:
>>>> On Dec 17, 2014, at 3:35 PM, Steve Donovan  =
wrote:
>>>>=20
>>>>=20
>>>> On 12/17/14 1:00 PM, Ben Campbell wrote:
>>>>>> On Dec 17, 2014, at 12:34 PM, Steve Donovan  wrote:
>>>>>>=20
>>>>>>> Okay, new picture:
>>>>>>>=20
>>>>>>>=20
>>>>>>>> On Dec 17, 2014, at 11:26 AM, Steve Donovan 
>>>>>>>> wrote:
>>>>>>>>=20
>>>>>>>> Ben,
>>>>>>>>=20
>>>>>>>> The value of the Origin-Host matters greatly here.  In both cases,=
 what S needs to know is if there is a reacting node for traffic coming fro=
m C1 and if there is a reacting node for traffic coming from C2.
>>>>>>>>=20
>>>>>>> There is no assumption in the draft right now that we have a correl=
ation between reacting nodes and clients. That might be required for client=
-targed OLRs, but we don't have those yet.
>>>>>>>=20
>>>>>>> Consider a different picture. In this case, C never supports DOIC. =
the reacting node role happens either at A1/A2 or at A3, depending on which=
 flow you look at.
>>>>>>>=20
>>>>>>>        A1---
>>>>>>>       /         \
>>>>>>> C --             -------A3------S
>>>>>>>       \         /
>>>>>>>         A2---
>>>>>>>=20
>>>>>>> Now, assume the same flows, but substitute A1 for C1, A2, for C2, a=
nd A3 for A. All requests now have the same origin-host.
>>>>>>>=20
>>>>>>> Before you say this is unrealistic: The issue is the same for any s=
ituation where one client can send traffic across multiple agents to the sa=
me destination. It doesn't matter if there is one or a million.
>>>>>>>=20
>>>>>> SRD> Yes, this is nasty.  With attribution S can detect the scenario=
.  I'm not sure what it does once it selects it.  This can be addressed to =
some degree by adding a deployment recommendation that  all agents taking o=
n reacting node functionality for a single endpoint  select the same algori=
thm.
>>>>> I think some sort of attribution is the long-term solution. Another o=
ption might be some sort of DCA state identifier, or a combination of the t=
wo. (e.g. multiple "virtual" reacting node at the same physical node.) The =
details will be non-trivial to figure out.
>>>>>=20
>>>>> But to close the loop, I think the _short_ term solution is to say th=
at, while a reporting node should not _initiate_ a change in algorithms dur=
ing an overload condition, it must still handle the situation where the rea=
cting node forces a change. We could go further to say that reacting node a=
lso should not initiate such a change, but we would have to recognize that =
there are scenarios where that guidance cannot be enforced, and the reporti=
ng node still has to handle them.
>>>>>=20
>>>>> We might need to think about what it means from an OCS perspective fo=
r a reporting node to send OLRs with different algorithms (or potentially o=
ther capability parameters) for the "same" overload event.
>>>> SRD> I think it is a better solution to stay with what we have now.  T=
he reporting node MUST NOT change the algorithm during an active overload c=
ondition.  If a reacting node advertises support for it, the reacting node =
is saying it will support that algorithm for the duration of any overload c=
ondition that happens prior to the reacting node changing the advertised al=
gorithm.  The change in advertised algorithm will take effect after the ove=
rload condition goes away.
>>>>=20
>>> I disagree. I don't think we want to allow the reporting node to ever i=
ndicate an algorithm that was not advertised in the request. That violates =
normative language earlier in the section that says the selected algorithm =
MUST be one of the ones advertised in the request. It can also cause proble=
ms for reacting nodes, where they get OLRs for an algorithm they don't unde=
rstand.
>> SRD> They clearly do understand the algorithm.  They advertised it befor=
e the overload report started.  We can change the normative language to cov=
er this exception.
>=20
> In my first scenario, this is not true. C2 (or A2)  _never_ understood th=
e rate algorithm, and never advertised support for it.
>=20
> The whole point of this exercise was to show that the reporting node cann=
ot, in the general case, distinguish between multiple reacting nodes with d=
ifferent capabilities, and a single reacting node that changes capabilities=
.
>=20
> By "general case", I mean no assumption that the reacting nodes are peers=
 with the reporting nodes, and no assumption that you can correlate origin-=
host values (in requests) to reacting-nodes.=20
>=20
>=20
>> I think the principle of minimizing work on an overloaded reporting node=
 is the more important principle here.  If the reacting node changes the ad=
vertised set of algorithms during an active overload condition then the ove=
rloaded reporting node will be required to send end-of-overload OLRs for th=
e previous algorithm and then send start-of-overload OLRs for the new algor=
ithm.  This seems complex at a time the overloaded node should be focusing =
on getting out of the overload condition.
>=20
> Sending an OLR that the reacting node does not understand will not help y=
ou get out of overload.
>=20
> I don't see how this is any more complex that if you simply have multiple=
 reacting nodes with different capabilities--and I don't see how to avoid s=
upporting that case.
>=20
>>>=20
>>> I think that's considerably more important that restricting the reporti=
ng node from changing algorithms (Which, btw, does no harm with the only al=
gorithms that we are seriously contemplating.We speculate that it might cau=
se harm for some future algorithm.)
>> SRD> We already have the restriction on the reporting node.
>=20
> We already have both restrictions, and they contradict. I believe the _ex=
isting_ restriction to not select an algorithm that is not advertised in th=
e request is more important than the _existing_ restriction to not change a=
lgorithms during an overload condition.
>=20
>=20
>>>=20
>>> Remember, this is not just about a single reacting node changing it's c=
apabilities, it's also about multiple reacting nodes with different capabil=
ities. We can't disallow one without disallowing the other.
>> SRD> Multiple reacting nodes with different capabilities is all the more=
 reason to hold things constant during an overload condition.
>=20
> I don't follow that. You seem to be pushing towards using the same algori=
thm for all reacting nodes once an overload condition starts. Is that your =
intent?  (Given the possibility that some future reacting node will only su=
pport "loss", that "same algorithm" would pretty much always need to be los=
s.)
>=20
>> I'm not proposing disallowing reacting nodes from changing the set of ca=
pabilities, I'm proposing that these changes don't take effect while there =
is an active overload condition.
>=20
> The problem exists even if no reacting node ever changes its capabilities=
.
>=20
>>>=20
>>>=20
>>>> SRD> I don't think we need to update the OCS in this document to handl=
e multiple algorithms.  This can be done in the extension drafts.  We might=
 want to make it clear, as it appears it isn't already, that a reacting nod=
e might need to support multiple algorithms at the same time.
>>> Do you mean reacting or reporting node in the last sentence? Assuming y=
ou mean it as written, the problem is not that a reacting node may need to =
support multiple algorithms at the same time. It's that it may get OLRs tha=
t it cannot act upon because it doesn't support the algorithm.
>> SRD> I meant reporting nodes.
>>>=20
>>> If, otoh, you meant reporting node, I don't understand how a reporting =
node can have multiple algorithms for the same overload event, without refl=
ecting that possibility in the OCS.
>> SRD> Yes, it will need to be reflected in the OCS.  We don't have multip=
le algorithms now so it isn't needed now.  I'm saying we might want to say =
it might me needed in the future.
>=20
> I'd rather not make each new algorithm redefine the basic structure of OC=
S.
>=20
> But, if you recall, my point was to say we need to _think_ about how this=
 impacts OCS, not that we necessarily need to change anything. Are you oppo=
sed to thinking about it? (And no, I don't think this short exchange quite =
counts as that.)
>=20
>>>=20
>>>=20
>>>=20
>>>>>=20
>>>=20
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Tue Dec 23 10:54:49 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8F41A1AB9 for ; Tue, 23 Dec 2014 10:54:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySEMrhnznxho for ; Tue, 23 Dec 2014 10:54:41 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47DC71A1AC3 for ; Tue, 23 Dec 2014 10:54:41 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sBNIsbSP030404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Dec 2014 18:54:38 GMT
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sBNIsZnk008009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Dec 2014 19:54:37 +0100
Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 23 Dec 2014 19:54:34 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.60]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0195.001; Tue, 23 Dec 2014 19:54:34 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "Wiehe, Ulrich (NSN - DE/Munich)" , ext Ben Campbell 
Thread-Topic: [Dime] Ulrich's suggested change #15
Thread-Index: AQHQE7dJhQB5e1nbwEev114RSsJu35yHeSWggAL2Z7uAAD8mAIAACZWAgAY/jwCAAU9ggIABPegggAglTQCAAYF28IAAH80AgAAaZ9CAAAAWgIAAFGEAgAAhJyA=
Date: Tue, 23 Dec 2014 18:54:34 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681523AD55@DEMUMBX014.nsn-intra.net>
References: <5486FE71.70205@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235215@DEMUMBX014.nsn-intra.net> <54884137.4050209@usdonovans.com> <5AB8BAC5-3CBD-432E-9631-74DF40795844@nostrum.com> <5489A498.5070203@usdonovans.com>  <5489EFAF.8010702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668152358E0@DEMUMBX014.nsn-intra.net> <549046D3.3090104@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815235AB9@DEMUMBX014.nsn-intra.net> <549826C8.1090809@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815239CB6@DEMUMBX014.nsn-intra.net> <1FC86658-AB09-4C11-9ED1-0C7FAFC542BE@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681523ACF5@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D90006681523AD21@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681523AD21@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.109]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 13170
X-purgate-ID: 151667::1419360878-00001177-94CABB9B/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qumYts73QLWLrYuUb87h3WkP5-8
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Ulrich's suggested change #15
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Dec 2014 18:54:46 -0000

V2l0aCB0aGlzIGNsYXJpZmljYXRpb24gSSB3aXRoZHJhdyBteSByZXF1ZXN0IGZvciBleHBsaWNp
dCBzdGF0ZW1lbnRzOyBzaW1wbHkgZGVsZXRpbmcgdGhlIHBhcmFncmFwaCBpcyBzdWZmaWNpZW50
Lg0KVWxyaWNoDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEaU1FIFttYWls
dG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IFdpZWhlLCBVbHJpY2gg
KE5TTiAtIERFL011bmljaCkNClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDIzLCAyMDE0IDU6NTQg
UE0NClRvOiBleHQgQmVuIENhbXBiZWxsDQpDYzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6
IFtEaW1lXSBVbHJpY2gncyBzdWdnZXN0ZWQgY2hhbmdlICMxNQ0KDQpUaGFuayB5b3UgZm9yIHRo
ZSBjbGFyaWZpY2F0aW9uLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZXh0
IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJlbkBub3N0cnVtLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBE
ZWNlbWJlciAyMywgMjAxNCA1OjQxIFBNDQpUbzogV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVu
aWNoKQ0KQ2M6IGV4dCBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTog
W0RpbWVdIFVscmljaCdzIHN1Z2dlc3RlZCBjaGFuZ2UgIzE1DQoNCg0KPiBPbiBEZWMgMjMsIDIw
MTQsIGF0IDk6NTUgQU0sIFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgPHVscmljaC53
aWVoZUBuc24uY29tPiB3cm90ZToNCj4gDQo+IFdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIGRv
aW5nIHRoaW5ncyB3cm9uZywgaS5lLiBzZW5kcyBhbiBPTFIgb2YgYSB0eXBlIHRoYXQgd2FzIG5v
dCBhZHZlcnRpemVkIChpbXBsaWNpdGx5IG9yIGV4cGxpY2l0bHkpLCBvciBzZW5kcyB0d28gT0xS
cyBvZiBzYW1lIHR5cGUsIGFsdGhvdWdoIHRoZSBzcGVjIHNheXMgIk1VU1QgTk9UIGRvIHNvIiwg
d2UgY2Fubm90IGV4cGVjdCB0aGUgcmVhY3Rpbmcgbm9kZSB0byBzb3J0IHRoaW5ncyBvdXQuDQoN
CkdpdmVuIHRoZSBjdXJyZW50IE1VU1QgTk9ULCBJIGFncmVlLiBBcyBJJ3ZlIG1lbnRpb25lZCBp
biB0aGUgcGFzdCwgd2UgZG9uJ3QgbmVlZCB0byBzcGVjaWZ5IGJlaGF2aW9yIG9uIHdoYXQgeW91
IGRvIHdoZW4gdGhlIHBlZXIgdmlvbGF0ZXMgdGhlIHByb3RvY29sLiBJZiBhIHJlYWN0aW5nIG5v
ZGUgcmVjZWl2ZXMgYW4gYW5zd2VyIHdpdGggdHdvIE9MUnMgb2YgdGhlIHNhbWUgdHlwZSwgb3Ig
d2l0aCBhbiBPTFIgb2YgYSB0eXBlIGl0IGRvZXNuJ3QgcmVjb2duaXplLCB3aGF0IGl0IGRvZXMg
aXMgbG9jYWwgcG9saWN5LiBJdCBjb3VsZCBpZ25vcmUgYWxsIGZ1cnRoZXIgRE9JQyBpbmZvcm1h
dGlvbiBmcm9tIHRoYXQgcmVhY3Rpbmcgbm9kZSwgYW5kIHRyZWF0IGl0IGxpa2UgYSBub24tc3Vw
cG9ydGluZyBub2RlLiBJdCBjb3VsZCBpZ25vcmUgYWxsIHRoZSBPTFJzIGluIHRoZSBtZXNzYWdl
LCBidXQgY29udGludWUgdG8gZXhjaGFuZ2UgT0MtUy1Gcy4gSXQgY291bGQgcHJvY2VzcyBzb21l
IChvciBvbmUpIG9mIHRoZSBPTFJzIGFuZCBpZ25vcmUgdGhlIHJlc3QuIEl0J3MgdXAgdG8gdGhl
IGltcGxlbWVudG9ycyB0byBkZWNpZGUuDQoNCkJUVywgd2UgZG9uJ3QgbmVlZCB0ZXh0IHRvIHNh
eSB0aGF0LCB1bmxlc3Mgd2Ugd2FudCB0byBhY3R1YWxseSBmYXZvciBvbmUgc3RyYXRlZ3kgb3Zl
ciBhbm90aGVyLg0KDQo+IEkgZG8gbm90IGFncmVlIHRvIHJlbGF4IHRoZSAiTVVTVCBOT1QgZG8g
c28iIHJlcXVpcmVtZW50IGZvciB0aGUgcmVwb3J0aW5nIG5vZGUuDQo+IA0KDQpJIGRpZCBub3Qg
c2VyaW91c2x5IGV4cGVjdCB1cyB0by4gSSBqdXN0IHRvc3NlZCBpdCBvdXQgYXMgc29tZXRoaW5n
IHRvIHRoaW5rIGFib3V0Lg0KDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG
cm9tOiBleHQgQmVuIENhbXBiZWxsIFttYWlsdG86YmVuQG5vc3RydW0uY29tXSANCj4gU2VudDog
VHVlc2RheSwgRGVjZW1iZXIgMjMsIDIwMTQgNDowNiBQTQ0KPiBUbzogV2llaGUsIFVscmljaCAo
TlNOIC0gREUvTXVuaWNoKQ0KPiBDYzogZXh0IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmcN
Cj4gU3ViamVjdDogUmU6IFtEaW1lXSBVbHJpY2gncyBzdWdnZXN0ZWQgY2hhbmdlICMxNQ0KPiAN
Cj4gSSBkb24ndCBvYmplY3QgdG8gYWxsb3dpbmcgdGhhdCBiZWhhdmlvci4gQnV0IHRoaW5raW5n
IG9mIGEgbGVzcyBleHRyZW1lIGNhc2UsIHdoZXJlIHlvdSBoYXZlIHR3byBPQy1PTFJzIGFuZCBv
bmx5IHJlY29nbml6ZSBvbmUsIEkgdGhpbmsgaXQgd291bGQgYmUgcG9vciBkZXNpZ24gdG8gaWdu
b3JlIHRoZSBvbmUgeW91IGRvIHJlY29nbml6ZS4gT1RPSCwgaXQncyBub3QgdGhlIElFVEYncyBq
b2IgdG8gcHJldmVudCBiYWQgZGVzaWduLCBhcyBsb25nIGFzIGl0J3MgaW50ZXJvcGVyYWJsZSBh
bmQgZG9lc24ndCBicmVhayBldmVyeW9uZSBlbHNlIChhbmQgdGhlIG5ldHdvcmsuKQ0KPiANCj4g
QnV0IHdlIG1pZ2h0IHdhbnQgdG8gY29uc2lkZXIgdGhlIGZhY3QgdGhhdCB0aGlzIHB1dHMgdGhl
IHdvcmsgdXBvbiB0aGUgb3ZlcmxvYWRlZCByZXBvcnRpbmcgbm9kZSB0byBtYWtlIHRoaW5ncyBy
aWdodCwgcmF0aGVyIHRoYW4gb24gdGhlIHJlYWN0aW5nIG5vZGUgdG8gZmlndXJlIGl0IG91dC4g
Rm9yIGV4YW1wbGUsIHRoZSB1c2UgY2FzZXMgSSd2ZSBkZXNjcmliZSBpbiBhIHNlcGFyYXRlIHRo
cmVhZCwgd2hlcmUgeW91IGhhdmUgbXVsdGlwbGUgcmVhY3Rpbmcgbm9kZXMgd2l0aCBkaWZmZXJl
bnQgY2FwYWJpbGl0aWVzLCBtaWdodCBjb3VsZCBiZSBtaXRpZ2F0ZWQgYnkgYWxsb3dpbmcgKG5v
dCByZXF1aXJpbmcpIHRoZSByZXBvcnRpbmcgbm9kZSBwdXQgdGhlIE9DLU9MUnMgZm9yIGJvdGgg
aW4gZWFjaCBhbnN3ZXIuIFdlIGRvbid0IGN1cnJlbnRseSBhbGxvdyB0aGF0IHVubGVzcyB0aGV5
IGFyZSBkaWZmZXJlbnQgdHlwZXMsIGJ1dCBJIHdvbmRlciBpZiB3ZSBzaG91bGQgdGhpbmsgYWJv
dXQgcmVsYXhpbmcgdGhhdC4NCj4gDQo+PiBPbiBEZWMgMjMsIDIwMTQsIGF0IDY6MzAgQU0sIFdp
ZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgPHVscmljaC53aWVoZUBuc24uY29tPiB3cm90
ZToNCj4+IA0KPj4gTm8sIHRoYXQgd2FzIG5vdCB3aGF0IEnigJltIGFmdGVyLg0KPj4gDQo+PiBJ
bWFnaW5lIHRoZSAodW5saWtlbHkpIGNhc2Ugd2hlcmUgYW4gYW5zd2VyIG1lc3NhZ2UgY29udGFp
bnMgaHVuZHJlZHMgb2YgT0MtT0xSIEFWUHMuDQo+PiANCj4+IEluIHRoaXMgY2FzZSBJIHdhbnQg
dGhlIHJlYWN0aW5nIG5vZGUgdG8gYmUgYWxsb3dlZA0KPj4gLSAgICAgICAgICBOb3QgdG8gc2Nh
biB0aHJvdWdoIGFsbCB0aGUgT0MtT0xSIEFWUHMgdG8gc2VlIHdoZXRoZXIgdGhlcmUgaXMgYSBz
dXBwb3J0ZWQgIGFuZCBub3QgZHVwbGljYXRlZCBPTFINCj4+IC0gICAgICAgICAgVG8gaWdub3Jl
IHRoZSBjb21wbGV0ZSBzZXQgb2YgT0MtT0xSIEFWUHMgaWYgYXQgbGVhc3Qgb25lIG9mIHRoZSBP
TFIgY29udGFpbnMgYW4gdW5zdXBwb3J0ZWQgcmVwb3J0LXR5cGUgb3IgYXQgbGVhc3QgdHdvIG9m
IHRoZSBPTFJzIGNvbnRhaW4gIHRoZSBzYW1lIHJlcG9ydCB0eXBlLg0KPj4gDQo+PiBBcyBzb29u
IGFzIHRoZSByZWFjdGluZyBub2RlIGRldGVjdHMgdGhhdCB0aGVyZSBpcyBzb21ldGhpbmcgd3Jv
bmcgd2l0aCB0aGUgc2V0IG9mIE9MUnMgaXQgbWF5IGlnbm9yZSB0aGUgY29tcGxldGUgc2V0IG9m
IE9MUnMuDQo+PiANCj4+IFJlZ2FyZHMNCj4+IFVscmljaA0KPj4gDQo+PiBGcm9tOiBleHQgU3Rl
dmUgRG9ub3ZhbiBbbWFpbHRvOnNyZG9ub3ZhbkB1c2Rvbm92YW5zLmNvbV0gDQo+PiBTZW50OiBN
b25kYXksIERlY2VtYmVyIDIyLCAyMDE0IDM6MTIgUE0NCj4+IFRvOiBXaWVoZSwgVWxyaWNoIChO
U04gLSBERS9NdW5pY2gpOyBCZW4gQ2FtcGJlbGwNCj4+IENjOiBkaW1lQGlldGYub3JnDQo+PiBT
dWJqZWN0OiBSZTogW0RpbWVdIFVscmljaCdzIHN1Z2dlc3RlZCBjaGFuZ2UgIzE1DQo+PiANCj4+
IEkgaGF2ZSBhZGRlZCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudHM6DQo+PiANCj4+ICAgV2hlbiBy
ZWNlaXZpbmcgYW4gYW5zd2VyIG1lc3NhZ2Ugd2l0aCBtdWx0aXBsZSBPTFJzIGFuZCBtdWx0aXBs
ZSBvZg0KPj4gICB0aGUgT0xScyBhcmUgb2YgdGhlIHNhbWUgc3VwcG9ydGVkIHJlcG9ydCB0eXBl
cywgYSByZXBvcnRpbmcgbm9kZQ0KPj4gICBTSE9VTEQgaWdub3JlIHRoZSBkdXBsaWNhdGVkIE9M
UnMuDQo+PiANCj4+ICAgQSByZWFjdGluZyBub2RlIFNIT1VMRCBpZ25vcmUgYW4gT0MtT0xSIHdp
dGggYSBPQy1SZXBvcnQtVHlwZSBBVlANCj4+ICAgdGhhdCBjb250YWlucyBhbiB1bnJlY29nbml6
ZWQgdmFsdWUuDQo+PiBSZWdhcmRzLA0KPj4gDQo+PiBTdGV2ZQ0KPj4gDQo+PiBPbiAxMi8xNy8x
NCAyOjQ5IEFNLCBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpIHdyb3RlOg0KPj4gWWVz
IHBsZWFzZS4NCj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IGV4
dCBTdGV2ZSBEb25vdmFuIFttYWlsdG86c3Jkb25vdmFuQHVzZG9ub3ZhbnMuY29tXSANCj4+IFNl
bnQ6IFR1ZXNkYXksIERlY2VtYmVyIDE2LCAyMDE0IDM6NTEgUE0NCj4+IFRvOiBXaWVoZSwgVWxy
aWNoIChOU04gLSBERS9NdW5pY2gpOyBCZW4gQ2FtcGJlbGwNCj4+IENjOiBkaW1lQGlldGYub3Jn
DQo+PiBTdWJqZWN0OiBSZTogW0RpbWVdIFVscmljaCdzIHN1Z2dlc3RlZCBjaGFuZ2UgIzE1DQo+
PiANCj4+IEknbGwgZGVsZXRlIHRoZSBwYXJhZ3JhcGguDQo+PiANCj4+IERvIHdlIG5lZWQgZXhw
bGljaXQgc3RhdGVtZW50cyBmb3IgdGhlIHR3byBjb25kaXRpb25zIGJlbG93Pw0KPj4gDQo+PiBT
dGV2ZQ0KPj4gDQo+PiANCj4+IE9uIDEyLzE1LzE0LCAxMTo1NiBBTSwgV2llaGUsIFVscmljaCAo
TlNOIC0gREUvTXVuaWNoKSB3cm90ZToNCj4+IFN0ZXZlLCBCZW4sDQo+PiANCj4+IEknbSBmaW5l
IHdpdGggZGVsZXRpbmcgdGhlIHBhcmFncmFwaC4NCj4+IEJ1dCBmb3IgbXkgY2xhcmlmaWNhdGlv
biBwbGVhc2UgY29uZmlybSB0aGF0IGlnbm9yaW5nIHRoZSBjb21wbGV0ZSBzZXQgb2YgT0xScyBp
cyBhbGxvd2VkIHdoZW4gb25lIG9mIHRoZXNlIE9MUnMgY29udGFpbnMgYSByZXBvcnQgdHlwZSB0
aGF0IHdhcyBub3QgYWR2ZXJ0aXplZCwgb3IgdHdvIG9mIHRoZSBPTFJzIGNvbnRhaW4gdGhlIHNh
bWUgcmVwb3J0IHR5cGUuDQo+PiANCj4+IFJlZ2FyZHMNCj4+IFVscmljaA0KPj4gDQo+PiANCj4+
IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IGV4dCBTdGV2ZSBEb25v
dmFuIFttYWlsdG86c3Jkb25vdmFuQHVzZG9ub3ZhbnMuY29tXQ0KPj4gU2VudDogVGh1cnNkYXks
IERlY2VtYmVyIDExLCAyMDE0IDg6MjYgUE0NCj4+IFRvOiBCZW4gQ2FtcGJlbGwNCj4+IENjOiBX
aWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBkaW1lQGlldGYub3JnDQo+PiBTdWJqZWN0
OiBSZTogW0RpbWVdIFVscmljaCdzIHN1Z2dlc3RlZCBjaGFuZ2UgIzE1DQo+PiANCj4+IA0KPj4g
T24gMTIvMTEvMTQsIDEyOjUxIFBNLCBCZW4gQ2FtcGJlbGwgd3JvdGU6DQo+PiBPbiBEZWMgMTEs
IDIwMTQsIGF0IDg6MDUgQU0sIFN0ZXZlIERvbm92YW4gPHNyZG9ub3ZhbkB1c2Rvbm92YW5zLmNv
bT4gd3JvdGU6DQo+PiANCj4+IEkgdGhvdWdodCB0aGlzIHBhcmFncmFwaCB3YXMgY292ZXJpbmcg
dW5yZWNvZ25pemVkIHZhbHVlcyBmb3IgYWxsIEFWUHMuDQo+PiBJIGFncmVlIHRoYXQncyB3aGF0
IGl0IGNvdmVyZWQuIEJ1dCBJIHRoaW5rIHdlIGZhaWxlZCB0byBjb3ZlciB0aGUgdW5yZWNvZ25p
emVkIEFWUCBjYXNlLiBJZiB3ZSBkb24ndCBoYXZlIGFueXRoaW5nIHRvIHNheSBiZXlvbmQgd2hh
dCA2NzMzIHNheXMsIHRoZW4gaXQgbWlnaHQgbm90IGJlIHN0cmljdGx5IG5lY2Vzc2FyeSwgYnV0
IGl0IG1pZ2h0IHN0aWxsIGJlIHdvcnRoIHNheWluZyB0aGF0ICJ1bnJlY29nbml6ZWQgc3ViLUFW
UHMgYXJlIHRyZWF0ZWQgYXMgcGVyIFJGQzY3MzMiLg0KPj4gVGhhdCBpcyBwcm9iYWJseSB3b3J0
aCBzYXlpbmcuDQo+PiAgIE1heWJlIGl0IGlzIGJldHRlciB0byByZW1vdmUgdGhlIHBhcmFncmFw
aCBlbnRpcmVseSBhbmQgbWFrZSBzdXJlIHRoYXQgdGhlIGRlZmluaXRpb24gb2YgZWFjaCBBVlAg
YWRkcmVzc2VzIHdoYXQgaXMgZG9uZSB3aXRoIHVucmVjb2duaXplZCB2YWx1ZXMuDQo+PiBQb3Nz
aWJseS4gVGhlcmUgYXJlIEFWUHMgd2hlcmUgdGhlcmUncyBubyBzdWNoIHRoaW5nIGFzIGFuIHVu
cmVjb2duaXplZCB2YWx1ZS4gVGhlcmUgbWF5IGJlIEFWUHMgd2hlcmUgdGhlIGFsbG93ZWQgdmFs
dWVzIHZhcnkgYnkgYWxnb3JpdGhtLiBJZiB3ZSBkbyB0YWtlIHRoYXQgcm91dGUsIHdlIHByb2Jh
Ymx5IG5lZWQgbGFuZ3VhZ2UgaGVyZSB0aGF0IHNheXMgdW5yZWNvZ25pemVkIHZhbHVlcyBhcmUg
aGFuZGxlZCBhcyBkZXNjcmliZWQgYnkgdGhlIEFWUCBkZWZpbml0aW9uIG9yIHRoZSBhbGdvcml0
aG0uDQo+PiBBZ3JlZWQuDQo+PiBTdGV2ZQ0KPj4gDQo+PiBPbiAxMi8xMC8xNCwgNToyNiBQTSwg
QmVuIENhbXBiZWxsIHdyb3RlOg0KPj4gT24gRGVjIDEwLCAyMDE0LCBhdCA2OjQ4IEFNLCBTdGV2
ZSBEb25vdmFuIDxzcmRvbm92YW5AdXNkb25vdmFucy5jb20+IHdyb3RlOg0KPj4gDQo+PiBVbHJp
Y2gsDQo+PiANCj4+IEFjdHVhbGx5LCB0aGUgd29yZGluZyB5b3Ugc3VnZ2VzdGVkIHdhc24ndCBx
dWl0ZSByaWdodC4gIEl0IHNob3VsZCBiZToNCj4+IA0KPj4gICAgV2hlbiByZWNlaXZpbmcgYW4g
T0MtT0xSIEFWUCB3aXRoIHVua25vd24gdmFsdWVzLCB0aGUgb3ZlcmxvYWQgcmVwb3J0DQo+PiAg
ICBTSE9VTEQgYmUgc2lsZW50bHkgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVzIGFuZCB0aGUg
ZXZlbnQgU0hPVUxEDQo+PiAgICBiZSBsb2dnZWQuDQo+PiANCj4+IEl0J3Mgbm90IGp1c3QgYWJv
dXQgcmVwb3J0IHR5cGUgdmFsdWVzIGJ1dCB1bmtub3duIHZhbHVlcyBmb3IgYW55IG9mIHRoZSBB
VlBzIGluIHRoZSBPTFIuDQo+PiANCj4+IFRoaXMgc2VlbXMgbGlrZSBhIGdvb2QgcmVxdWlyZW1l
bnQgdG8gaW5jbHVkZSBpbiB0aGUgc3BlY2lmaWNhdGlvbiB0byBlbnN1cmUgY29tbW9uIGJlaGF2
aW9yIGluIHJlYWN0aW5nIG5vZGVzLiAgSSBkb24ndCBmZWVsIHN0cm9uZ2x5IGFib3V0IHRoaXMg
YnV0IEkgd291bGQgbGlrZSB0byBoZWFyIG90aGVyIG9waW5pb25zLg0KPj4gSSB0aGluayB0aGlz
IGlzIHN0aWxsIG5vdCBxdWl0ZSBjb21wbGV0ZS4NCj4+IA0KPj4gSWYgeW91IHJlY2VpdmUgYSBz
dWItQVZQIHRoYXQgeW91IGRvbid0IHVuZGVyc3RhbmQsIHRoZW4geW91IHNob3VsZCBpZ25vcmUg
dGhhdCBzdWItYXZwLCBub3QgdGhlIHdob2xlIE9DLU9MUiBBVlAuICAoVW5sZXNzIG9mIGNvdXJz
ZSB0aGUgdW5rbm93biBBVlAgaGFzIHRoZSBtLWJpdCBzZXQuKSBJZiB5b3UgcmVjZWl2ZSBhIGtu
b3duIHN1Yi1BVlAsIHdpdGggYSB2YWx1ZSB5b3UgZG9uJ3QgdW5kZXJzdGFuZCwgdGhlIGJlaGF2
aW9yIHNob3VsZCBiZSBBVlAgc3BlY2lmaWMuIEZvciBSZXBvcnQtVHlwZSwgdGhhdCBtZWFucyBp
Z25vcmUgdGhlIHdob2xlIE9MUi4NCj4+IA0KPj4gSXQncyBub3QgY2xlYXIgdG8gbWUgd2hldGhl
ciB0aGUgb3JpZ2luYWwgdGV4dCB3YXMgYWJvdXQgYXJiaXRyYXJ5IGF2cHMsIG9yIFJlcG9ydC1U
eXBlLg0KPj4gDQo+PiBTdGV2ZQ0KPj4gDQo+PiBPbiAxMi85LzE0LCAxMTowNCBBTSwgV2llaGUs
IFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSB3cm90ZToNCj4+IEhpIFN0ZXZlLA0KPj4gDQo+PiBJ
IHRoaW5rIGl0IHdhcyBwb2ludGVkIG91dCBieSBCZW4gdGhhdCB3ZSBkbyBub3Qgc3BlY2lmeSBi
ZWhhdmlvdXIgb2YgYSBub2RlIGZvciBjYXNlcyB3aGVyZSBpdCBkZXRlY3RzIHRoYXQgYW5vdGhl
ciBub2RlIGlzIGJyZWFraW5nIHRoZSBydWxlLg0KPj4gVGhlIHJ1bGUgaXM6DQo+PiAgICAgQSBy
ZXBvcnRpbmcgbm9kZSBNVVNUIE5PVCBzZW5kIG92ZXJsb2FkIHJlcG9ydHMgb2YgYSB0eXBlIHRo
YXQgaGFzDQo+PiAgICAgbm90IGJlZW4gYWR2ZXJ0aXNlZCBhcyBzdXBwb3J0ZWQgYnkgdGhlIHJl
YWN0aW5nIG5vZGUuDQo+PiBTZWUgc2VjdGlvbiA0LjIuMy4NCj4+IA0KPj4gUmVnYXJkcw0KPj4g
VWxyaWNoDQo+PiANCj4+ICAgIEZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v
cmddIE9uIEJlaGFsZiBPZiBleHQgU3RldmUgRG9ub3Zhbg0KPj4gU2VudDogVHVlc2RheSwgRGVj
ZW1iZXIgMDksIDIwMTQgMjo1MiBQTQ0KPj4gVG86IGRpbWVAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6
IFtEaW1lXSBVbHJpY2gncyBzdWdnZXN0ZWQgY2hhbmdlICMxNQ0KPj4gDQo+PiBVbHJpY2gsDQo+
PiANCj4+IEZvciB5b3VyIHN1Z2dlc3RlZCBjaGFuZ2UgIzE1Og0KPj4gU2VjdGlvbiA0LjIuMS4z
LCA0dGggcGFyYWdyYXBoOg0KPj4gRXhpc3RpbmcgdGV4dDoNCj4+ICAgICBXaGVuIHJlY2Vpdmlu
ZyBhbiBPQy1PTFIgQVZQcyB3aXRoIHVua25vd24gdmFsdWVzLCBhIHJlYWN0aW5nIG5vZGUNCj4+
ICAgICBTSE9VTEQgYmUgc2lsZW50bHkgZGlzY2FyZGVkIGJ5IHJlYWN0aW5nIG5vZGVzIGFuZCB0
aGUgZXZlbnQgU0hPVUxEDQo+PiAgICAgYmUgbG9nZ2VkLg0KPj4gQ29tbWVudDogdGV4dCBpcyBj
b25mdXNpbmcuIE1heWJlIHRoZSBpbnRlbnRpb24gd2FzIHRvIHNheToNCj4+ICAgICBXaGVuIHJl
Y2VpdmluZyBhbiBPQy1PTFIgQVZQcyB3aXRoIGFuIHVuc3VwcG9ydGVkIHJlcG9ydCB0eXBlIHZh
bHVlLCBhIHJlYWN0aW5nIG5vZGUNCj4+ICAgICBTSE9VTEQgc2lsZW50bHkgZGlzY2FyZGVkIHRo
ZSBPQy1PTFIgQVZQIGFuZCB0aGUgZXZlbnQgU0hPVUxEDQo+PiAgICAgYmUgbG9nZ2VkLg0KPj4g
QnV0IGV2ZW4gdGhhdCBpcyBub3QgY29ycmVjdC4NCj4+IFByb3Bvc2FsOiBSZW1vdmUgdGhlIHBh
cmFncmFwaC4NCj4+IFRoZSBpbnRlbnQgd2FzIHRoYXQgYW4gT0MtT0xSIHRoYXQgY29udGFpbnMg
dW5rbm93biB2YWx1ZXMgc2hvdWxkIGJlIGRpc2NhcmRlZC4gIEkgYWdyZWUgdGhhdCB0aGUgd29y
ZGluZyBuZWVkcyB0byBiZSBjaGFuZ2VzIGFzIHlvdSBzdWdnZXN0ZWQuICBJIGRvbid0IGFncmVl
IHdpdGggcmVtb3ZpbmcgdGhlIHBhcmFncmFwaC4gIENhbiB5b3UgZWxhYm9yYXRlIG9uIHdoeSB5
b3UgdGhpbmsgaXQgaXMgbm90IGNvcnJlY3Qgd2hlbiBjaGFuZ2VkIGFzIHlvdSBzdWdnZXN0ZWQ/
DQo+PiANCj4+IFJlZ2FyZHMsDQo+PiANCj4+IFN0ZXZlDQo+PiANCj4+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBEaU1FIG1haWxpbmcgbGlzdA0K
Pj4gRGlNRUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9kaW1lDQo+PiANCj4+IA0KPj4gDQo+PiANCj4gDQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9y
Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo=


From nobody Wed Dec 24 09:59:45 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3AB1A1B14 for ; Mon, 22 Dec 2014 09:04:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.747
X-Spam-Level: **
X-Spam-Status: No, score=2.747 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X43eWfERLbKl for ; Mon, 22 Dec 2014 09:04:27 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64DA61A1B0A for ; Mon, 22 Dec 2014 09:04:27 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64596 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y36P9-0006bs-8P for dime@ietf.org; Mon, 22 Dec 2014 09:04:26 -0800
Message-ID: <54984F17.6020406@usdonovans.com>
Date: Mon, 22 Dec 2014 11:04:23 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/mixed; boundary="------------000005080501070401070001"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/jYfADh8cAVRqU1CZ6VTKcOV60TM
X-Mailman-Approved-At: Wed, 24 Dec 2014 09:59:41 -0800
Subject: [Dime] Updated DOIC-06
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Dec 2014 17:04:47 -0000

This is a multi-part message in MIME format.
--------------000005080501070401070001
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

All,

I've updated DOIC-06.  The changes and open issues are recorded below.

I've attached the diff and the latest -06 draft.

Regards,

Steve

-----


Ulrich's suggested changes:

1, 9, 10, 15, 16

Still open:

12

Ben's suggested changes:

Most of Ben's editorial changes.
DOIC WGLC: OC-Reduction-Percentage default value
DOIC WGLC: Implicit values for OC-OLR
DOIC WGLC: loss algorithm behavior with expiring OLRs
DOIC WGLC: Requirement for OC-Feature-Vector values
DOIC WGLC: Sequence Number uniqueness

Ben's comments unresolved:

DOIC WGLC: duration unit
DOIC WGLC: Changing Algorithms
OCS Handling
Mandatory sub-avp handling

--------------000005080501070401070001
Content-Type: text/plain; charset=UTF-8;
 name="draft-ietf-dime-ovli-06.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="draft-ietf-dime-ovli-06.txt"





Diameter Maintenance and Extensions (DIME)              J. Korhonen, Ed.
Internet-Draft                                                  Broadcom
Intended status: Standards Track                         S. Donovan, Ed.
Expires: June 25, 2015                                       B. Campbell
                                                                  Oracle
                                                               L. Morand
                                                             Orange Labs
                                                       December 22, 2014


                Diameter Overload Indication Conveyance
                      draft-ietf-dime-ovli-06.txt

Abstract

   This specification defines a base solution for Diameter overload
   control, referred to as Diameter Overload Indication Conveyance
   (DOIC).

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 25, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Korhonen, et al.          Expires June 25, 2015                 [Page 1]

Internet-Draft                    DOIC                     December 2014


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology and Abbreviations . . . . . . . . . . . . . . . .   4
   3.  Conventions Used in This Document . . . . . . . . . . . . . .   5
   4.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Piggybacking  . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  DOIC Capability Announcement  . . . . . . . . . . . . . .   7
     4.3.  DOIC Overload Condition Reporting . . . . . . . . . . . .   9
     4.4.  DOIC Extensibility  . . . . . . . . . . . . . . . . . . .  11
     4.5.  Simplified Example Architecture . . . . . . . . . . . . .  11
   5.  Solution Procedures . . . . . . . . . . . . . . . . . . . . .  12
     5.1.  Capability Announcement . . . . . . . . . . . . . . . . .  12
       5.1.1.  Reacting Node Behavior  . . . . . . . . . . . . . . .  12
       5.1.2.  Reporting Node Behavior . . . . . . . . . . . . . . .  13
       5.1.3.  Agent Behavior  . . . . . . . . . . . . . . . . . . .  14
     5.2.  Overload Report Processing  . . . . . . . . . . . . . . .  15
       5.2.1.  Overload Control State  . . . . . . . . . . . . . . .  15
       5.2.2.  Reacting Node Behavior  . . . . . . . . . . . . . . .  19
       5.2.3.  Reporting Node Behavior . . . . . . . . . . . . . . .  20
     5.3.  Protocol Extensibility  . . . . . . . . . . . . . . . . .  21
   6.  Loss Algorithm  . . . . . . . . . . . . . . . . . . . . . . .  22
     6.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  22
     6.2.  Reporting Node Behavior . . . . . . . . . . . . . . . . .  23
     6.3.  Reacting Node Behavior  . . . . . . . . . . . . . . . . .  23
   7.  Attribute Value Pairs . . . . . . . . . . . . . . . . . . . .  24
     7.1.  OC-Supported-Features AVP . . . . . . . . . . . . . . . .  24
     7.2.  OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . .  25
     7.3.  OC-OLR AVP  . . . . . . . . . . . . . . . . . . . . . . .  25
     7.4.  OC-Sequence-Number AVP  . . . . . . . . . . . . . . . . .  26
     7.5.  OC-Validity-Duration AVP  . . . . . . . . . . . . . . . .  26
     7.6.  OC-Report-Type AVP  . . . . . . . . . . . . . . . . . . .  26
     7.7.  OC-Reduction-Percentage AVP . . . . . . . . . . . . . . .  26
     7.8.  Attribute Value Pair flag rules . . . . . . . . . . . . .  27
   8.  Error Response Codes  . . . . . . . . . . . . . . . . . . . .  27
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28
     9.1.  AVP codes . . . . . . . . . . . . . . . . . . . . . . . .  28
     9.2.  New registries  . . . . . . . . . . . . . . . . . . . . .  28
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  29
     10.1.  Potential Threat Modes . . . . . . . . . . . . . . . . .  29
     10.2.  Denial of Service Attacks  . . . . . . . . . . . . . . .  30
     10.3.  Non-Compliant Nodes  . . . . . . . . . . . . . . . . . .  31
     10.4.  End-to End-Security Issues . . . . . . . . . . . . . . .  31
   11. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  32
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  33



Korhonen, et al.          Expires June 25, 2015                 [Page 2]

Internet-Draft                    DOIC                     December 2014


     12.1.  Normative References . . . . . . . . . . . . . . . . . .  33
     12.2.  Informative References . . . . . . . . . . . . . . . . .  33
   Appendix A.  Issues left for future specifications  . . . . . . .  33
     A.1.  Additional traffic abatement algorithms . . . . . . . . .  33
     A.2.  Agent Overload  . . . . . . . . . . . . . . . . . . . . .  34
     A.3.  New Error Diagnostic AVP  . . . . . . . . . . . . . . . .  34
   Appendix B.  Deployment Considerations  . . . . . . . . . . . . .  34
   Appendix C.  Requirements Conformance Analysis  . . . . . . . . .  34
     C.1.  Deferred Requirements . . . . . . . . . . . . . . . . . .  34
     C.2.  Detection of non-supporting Intermediaries  . . . . . . .  35
     C.3.  Implicit Application Indication . . . . . . . . . . . . .  35
     C.4.  Stateless Operation . . . . . . . . . . . . . . . . . . .  35
     C.5.  No New Vulnerabilities  . . . . . . . . . . . . . . . . .  36
     C.6.  Detailed Requirements . . . . . . . . . . . . . . . . . .  36
       C.6.1.  General . . . . . . . . . . . . . . . . . . . . . . .  36
       C.6.2.  Performance . . . . . . . . . . . . . . . . . . . . .  37
       C.6.3.  Heterogeneous Support for Solution  . . . . . . . . .  40
       C.6.4.  Granular Control  . . . . . . . . . . . . . . . . . .  41
       C.6.5.  Priority and Policy . . . . . . . . . . . . . . . . .  42
       C.6.6.  Security  . . . . . . . . . . . . . . . . . . . . . .  43
       C.6.7.  Flexibility and Extensibility . . . . . . . . . . . .  44
   Appendix D.  Considerations for Applications Integrating the DOIC
                Solution . . . . . . . . . . . . . . . . . . . . . .  45
     D.1.  Application Classification  . . . . . . . . . . . . . . .  45
     D.2.  Application Type Overload Implications  . . . . . . . . .  46
     D.3.  Request Transaction Classification  . . . . . . . . . . .  47
     D.4.  Request Type Overload Implications  . . . . . . . . . . .  48
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  50

1.  Introduction

   This specification defines a base solution for Diameter overload
   control, referred to as Diameter Overload Indication Conveyance
   (DOIC), based on the requirements identified in [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.

   A new application specification can incorporate the overload control
   mechanism specified in this document by making it mandatory to
   implement for the application and referencing this specification
   normatively.  It is the responsibility of the Diameter application
   designers to define how overload control mechanisms works on that
   application.



Korhonen, et al.          Expires June 25, 2015                 [Page 3]

Internet-Draft                    DOIC                     December 2014


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

2.  Terminology and Abbreviations

   Abatement

      Reaction to receipt of an overload report resulting in a reduction
      in traffic sent to the reporting node.  Abatement actions include
      diversion and throttling.

   Abatement Algorithm

      An extensible mechanism requested by reporting nodes and used by
      reacting nodes to reduce the amount of traffic sent during an
      occurrence of overload control.

   Diversion

      An overload abatement mechanism, where the reacting node selects
      alternate destinations or paths for for requests.

   Host-Routed Requests

      Requests that a reacting node knows will be served by a particular
      host, either due to the presence of a Destination-Host AVP, or by
      some other local knowledge on the part of the reacting node.

   Overload Control State (OCS)

      Internal state maintained by a reporting or reacting node
      describing occurrences of overload control.

   Overload Report (OLR)

      Overload control information for a particular overload occurrence
      sent by a reporting node.

   Reacting Node

      A Diameter node that acts upon an overload report.

   Realm-Routed Requests




Korhonen, et al.          Expires June 25, 2015                 [Page 4]

Internet-Draft                    DOIC                     December 2014


      Requests that a reacting node does not know which host will
      service the request.

   Reporting Node

      A Diameter node that generates an overload report.  (This may or
      may not be the overloaded node.)

   Throttling

      A mechanism for overload abatement that limits the number of
      requests sent by the DIOC reacting node.  Throttling can include a
      Diameter Client choosing to not send requests, or a Diameter Agent
      or Server rejecting requests with appropriate error responses.  In
      both cases the result of the throttling is a permanent rejection
      of the transaction.



3.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

4.  Solution Overview

   The Diameter Overload Information Conveyance (DOIC) solution allows
   Diameter nodes to request other Diameter nodes to perform overload
   abatement actions, that is, actions to reduce the load offered to the
   overloaded node or realm.

   A Diameter node that supports DOIC is known as a "DOIC node".  Any
   Diameter node can act as a DOIC node, including Diameter Clients,
   Diameter Servers, and Diameter Agents.  DOIC nodes are further
   divided into "Reporting Nodes" and "Reacting Nodes."  A reporting
   node requests overload abatement by sending Overload Reports (OLR).

   A reacting node acts upon OLRs, and performs whatever actions are
   needed to fulfill the abatement requests included in the OLRs.  A
   Reporting node may report overload on its own behalf, or on behalf of
   other nodes.  Likewise, a reacting node may perform overload
   abatement on its own behalf, or on behalf of other nodes.

   A Diameter node's role as a DOIC node is independent of its Diameter
   role.  For example, Diameter Agents may act as DOIC nodes, even
   though they are not endpoints in the Diameter sense.  Since Diameter
   enables bi-directional applications, where Diameter Servers can send



Korhonen, et al.          Expires June 25, 2015                 [Page 5]

Internet-Draft                    DOIC                     December 2014


   requests towards Diameter Clients, a given Diameter node can
   simultaneously act as both a reporting node and a reacting node.

   Likewise, a Diameter Agent may act as a reacting node from the
   perspective of upstream nodes, and a reporting node from the
   perspective of downstream nodes.

   DOIC nodes do not generate new messages to carry DOIC related
   information.  Rather, they "piggyback" DOIC information over existing
   Diameter messages by inserting new AVPs into existing Diameter
   requests and responses.  Nodes indicate support for DOIC, and any
   needed DOIC parameters, by inserting an OC-Supported-Features AVP
   (Section 7.2) into existing requests and responses.  Reporting nodes
   send OLRs by inserting OC-OLR AVPs (Section 7.3).

   A given OLR applies to the Diameter realm and application of the
   Diameter message that carries it.  If a reporting node supports more
   than one realm and/or application, it reports independently for each
   combination of realm and application.  Similarly, the OC-Supported-
   Features AVP applies to the realm and application of the enclosing
   message.  This implies that a node may support DOIC for one
   application and/or realm, but not another, and may indicate different
   DOIC parameters for each application and realm for which it supports
   DOIC.

   Reacting nodes perform overload abatement according to an agreed-upon
   abatement algorithm.  An abatement algorithm defines the meaning of
   some of the parameters of an OLR and the procedures required for
   overload abatement.  An overload abatement algorithm separates
   Diameter requests into two sets.  The first set contains the requests
   that are to undergo overload abatement treatment of either throttling
   or diversion.  The second set contains the requests that are to be
   given normal routing treatment.  This document specifies a single
   must-support algorithm, namely the "loss" algorithm (Section 6).
   Future specifications may introduce new algorithms.

   Overload conditions may vary in scope.  For example, a single
   Diameter node may be overloaded, in which case reacting nodes may
   attempt to send requests to other destinations.  On the other hand,
   an entire Diameter realm may be overloaded, in which case such
   attempts would do harm.  DOIC OLRs have a concept of "report type"
   (Section 7.6), where the type defines such behaviors.  Report types
   are extensible.  This document defines report types for overload of a
   specific host, and for overload of an entire realm.

   DOIC works through non supporting Diameter Agents that properly pass
   unknown AVPs unchanged.




Korhonen, et al.          Expires June 25, 2015                 [Page 6]

Internet-Draft                    DOIC                     December 2014


4.1.  Piggybacking

   There is no new Diameter application defined to carry overload
   related AVPs.  The overload control AVPs defined in this
   specification have been designed to be piggybacked on top of existing
   application messages.  This is made possible by adding the optional
   overload control AVPs OC-OLR and OC-Supported-Features into existing
   commands.

   Reacting nodes indicate support for DOIC by including the OC-
   Supported-Features AVP in all request messages originated or relayed
   by the reacting node.

   Reporting nodes indicate support for DOIC by including the OC-
   Supported-Features AVP in all answer messages originated or relayed
   by the reporting node that are in response to a request that
   contained the OC-Supported-Features AVP.  Reporting nodes may include
   overload reports using the OC-OLR AVP in answer messages.

   Note that the overload control solution does not have fixed server
   and client roles.  The DOIC node role is determined based on the
   message type: whether the message is a request (i.e. sent by a
   "reacting node") or an answer (i.e. sent by a "reporting node").
   Therefore, in a typical "client-server" deployment, the Diameter
   Client may report its overload condition to the Diameter Server for
   any Diameter Server initiated message exchange.  An example of such
   is the Diameter Server requesting a re-authentication from a Diameter
   Client.

4.2.  DOIC Capability Announcement

   The DOIC solution supports the ability for Diameter nodes to
   determine if other nodes in the path of a request support the
   solution.  This capability is referred to as DOIC Capability
   Announcement (DCA) and is separate from Diameter Capability Exchange.

   The DCA mechanism uses the OC-Supported-Features AVPs to indicate the
   Diameter overload features supported.

   The first node in the path of a Diameter request that supports the
   DOIC solution inserts the OC-Supported-Features AVP in the request
   message.

   The individual features supported by the DOIC nodes are indicated in
   the OC-Feature-Vector AVP.  Any semantics associated with the
   features will be defined in extension specifications that introduce
   the features.




Korhonen, et al.          Expires June 25, 2015                 [Page 7]

Internet-Draft                    DOIC                     December 2014


      Note: As discussed elsewhere in the document, agents in the path
      of the request can modify the OC-Supported-Features AVP.

      Note: The DOIC solution must support deployments where Diameter
      Clients and/or Diameter Servers do not support the DOIC solution.
      In this scenario, Diameter Agents that support the DOIC solution
      may handle overload abatement for the non supporting Diameter
      nodes.  In this case the DOIC agent will insert the OC-Supported-
      Features AVP in requests that do not already contain one, telling
      the reporting node that there is a DOIC node that will handle
      overload abatement.  For transactions where there was an OC-
      Supporting-Features AVP in the request, the agent will insert the
      OC-Supported-Features AVP in answers, telling the reacting node
      that there is a reporting node.

   The OC-Feature-Vector AVP will always contain an indication of
   support for the loss overload abatement algorithm defined in this
   specification (see Section 6).  This ensures that a reporting node
   always supports at least one of the advertized abatement algorithms
   received in a request messages.

   The reporting node inserts the OC-Supported-Features AVP in all
   answer messages to requests that contained the OC-Supported-Features
   AVP.  The contents of the reporting node's OC-Supported-Features AVP
   indicate the set of Diameter overload features supported by the
   reporting node.  This specification defines one exception - the
   reporting node only includes an indication of support for one
   overload abatement algorithm, independent of the number of overload
   abatement algorithms actually supported by the reacting node.  The
   overload abatement algorithm indicated is the algorithm that the
   reporting node intends to use should it enter an overload condition.
   Reacting nodes can use the indicated overload abatement algorithm to
   prepare for possible overload reports and must use the indicated
   overload abatement algorithm if traffic reduction is actually
   requested.

      Note that the loss algorithm defined in this document is a
      stateless abatement algorithm.  As a result it does not require
      any actions by reacting nodes prior to the receipt of an overload
      report.  Stateful abatement algorithms that base the abatement
      logic on a history of request messages sent might require reacting
      nodes to maintain state in advance of receiving an overload report
      to ensure that the overload reports can be properly handled.

   Reporting nodes can change the overload abatement algorithm indicated
   in the OC-Feature-Vector AVP if the reporting node is not currently
   in an overload condition and sending overload reports.  The reporting




Korhonen, et al.          Expires June 25, 2015                 [Page 8]

Internet-Draft                    DOIC                     December 2014


   node is not allowed to change the overload abatement algorithm while
   the reporting node is in an overload condition.

   The DCA mechanism must also allow the scenario where the set of
   features supported by the sender of a request and by agents in the
   path of a request differ.  In this case, the agent can update the OC-
   Supported-Features AVP to reflect the mixture of the two sets of
   supported features.

      Note: The logic to determine if the content of the OC-Supported-
      Features AVP should be changed is out-of-scope for this document,
      as is the logic to determine the content of a modified OC-
      Supported-Features AVP.  These are left to implementation
      decisions.  Care must be taken not to introduce interoperability
      issues for downstream or upstream DOIC nodes.

4.3.  DOIC Overload Condition Reporting

   As with DOIC capability announcement, overload condition reporting
   uses new AVPs (Section 7.3) to indicate an overload condition.

   The OC-OLR AVP is referred to as an overload report.  The OC-OLR AVP
   includes the type of report, a sequence number, the length of time
   that the report is valid and abatement algorithm specific AVPs.

   Two types of overload reports are defined in this document: host
   reports and realm reports.

   A report of type "HOST_REPORT" is sent to indicate the overload of a
   specific Diameter node for the application-id indicated in the
   transaction.  When receiving an OLR of type host, a reacting node
   applies overload abatement to what is referred to in this document as
   host-routed requests.  The reacting node applies overload abatement
   on those host-routed requests which the reacting node knows will be
   served by the server that matches the Origin-Host AVP of the received
   message that contained the received OLR of type host.

   A report of type "REALM_REPORT" is sent to indicate the overload of
   all Diameter nodes within a realm for the application-id indicated in
   the transaction.  When receiving an OLR of type realm, a reacting
   node applies overload abatement to what is referred to in this
   document as realm-routed requests.  The reacting node applies
   overload abatement on those realm-routed requests which contain a
   Destination-Realm AVP that matches the Origin-Realm AVP of the
   received message that contained the received OLR of type realm.

   This document assumes that there is a single source for realm-reports
   for a given realm, or that if multiple nodes can send realm reports,



Korhonen, et al.          Expires June 25, 2015                 [Page 9]

Internet-Draft                    DOIC                     December 2014


   that each such node has full knowledge of the overload state of the
   entire realm.  A reacting node cannot distinguish between receiving
   realm-reports from a single node, or from multiple nodes.

      Note: Known issues exist if multiple sources for overload reports
      which apply to the same Diameter entity exist.  Reacting nodes
      have no way of determining the source and, as such, will treat
      them as coming from a single source.  Variance in sequence numbers
      between the two sources can then cause incorrect overload
      abatement treatment to be applied for indeterminate periods of
      time.

   Reporting nodes are responsible for determining the need for a
   reduction of traffic.  The method for making this determination is
   implementation specific and depend on the type of overload report
   being generated.  A host-report might be generated by tracking use of
   resources required by the host to handle transactions for the
   Diameter application.  A realm-report generally impacts the traffic
   sent to multiple hosts and, as such, requires tracking the capacity
   of all servers able to handle realm- routed requests for the
   application and realm.

   Once a reporting node determines the need for a reduction in traffic,
   it uses the DOIC defined AVPs to report on the condition.  These AVPs
   are included in answer messages sent or relayed by the reporting
   node.  The reporting node indicates the overload abatement algorithm
   that is to be used to handle the traffic reduction in the OC-
   Supported-Features AVP.  The OC-OLR AVP is used to communicate
   information about the requested reduction.

   Reacting nodes, upon receipt of an overload report, applying the
   overload abatement algorithm to traffic impacted by the overload
   report.  The method used to determine the requests that are to
   receive overload abatement treatment is dependent on the abatement
   algorithm.  The loss abatement algorithm is defined in this document
   (Section 6).  Other abatement algorithms can be defined in extensions
   to the DOIC solutions.

   Two types of overload abatement treatment are defined, diversion and
   throttling.  Reacting nodes are responsible for determining which
   treatment is appropriate for individual requests.

   As the conditions that lead to the generation of the overload report
   change the reporting node can send new overload reports requesting
   greater reduction if the condition gets worse or less reduction if
   the condition improves.  The reporting node sends an overload report
   with a duration of zero to indicate that the overload condition has
   ended and abatement is no longer needed.



Korhonen, et al.          Expires June 25, 2015                [Page 10]

Internet-Draft                    DOIC                     December 2014


   The reacting node also determines when the overload report expires
   based on the OC-Validity-Duration AVP in the overload report and
   stops applying the abatement algorithm when the report expires.

4.4.  DOIC Extensibility

   The DOIC solution is designed to be extensible.  This extensibility
   is based on existing Diameter based extensibility mechanisms, along
   with the DOIC capability announcement mechanism.

   There are multiple categories of extensions that are expected.  This
   includes the definition of new overload abatement algorithms, the
   definition of new report types and the definition of new scopes of
   messages impacted by an overload report.

   A DOIC node communicates supported features by including them in the
   OC-Feature-Vector AVP, as a sub-AVP of OC-Supported-Features.  Any
   non-backwards compatible DOIC extensions define new values for the
   OC-Feature-Vector AVP.  DOIC extensions also have the ability to add
   new AVPs to the OC-Supported-Features AVP, if additional information
   about the new feature is required.

   Overload reports can be also extended by adding new sub-AVPs to the
   OC-OLR AVP, allowing reporting nodes to communicate additional
   information about handling an overload condition.

   If necessary, new extensions can also define new AVPs that are not
   part of the OC-Supported-Features and OC-OLR group AVPs.  It is,
   however, recommended that DOIC extensions use the OC-Supported-
   Features AVP and OC-OLR AVP to carry all DOIC related AVPs.

4.5.  Simplified Example Architecture

   Figure 1 illustrates the simplified architecture for Diameter
   overload information conveyance.
















Korhonen, et al.          Expires June 25, 2015                [Page 11]

Internet-Draft                    DOIC                     December 2014


    Realm X                                  Same or other Realms
   <--------------------------------------> <---------------------->


      +--^-----+                 : (optional) :
      |Diameter|                 :            :
      |Server A|--+     .--.     : +---^----+ :     .--.
      +--------+  |   _(    `.   : |Diameter| :   _(    `.   +---^----+
                  +--(        )--:-|  Agent |-:--(        )--|Diameter|
      +--------+  | ( `  .  )  ) : +-----^--+ : ( `  .  )  ) | Client |
      |Diameter|--+  `--(___.-'  :            :  `--(___.-'  +-----^--+
      |Server B|                 :            :
      +---^----+                 :            :

                          End-to-end Overload Indication
             1)  <----------------------------------------------->
                             Diameter Application Y

                  Overload Indication A    Overload Indication A'
             2)  <----------------------> <---------------------->
                 Diameter Application Y   Diameter Application Y



     Figure 1: Simplified architecture choices for overload indication
                                 delivery

   In Figure 1, the Diameter overload indication can be conveyed (1)
   end-to-end between servers and clients or (2) between servers and
   Diameter agent inside the realm and then between the Diameter agent
   and the clients.

5.  Solution Procedures

   This section outlines the normative behavior for the DOIC solution.

5.1.  Capability Announcement

   This section defines DOIC Capability Announcement (DCA) behavior.

5.1.1.  Reacting Node Behavior

   A reacting node MUST include the OC-Supported-Features AVP in all
   requests.  It MAY include the OC-Feature-Vector AVP, as a sub-avp of
   OC-Supported-Features.  If it does so, it MUST indicate support for
   the "loss" algorithm.  If the reacting node is configured to support
   features (including other algorithms) in addition to the loss
   algorithm, it MUST indicate such support in an OC-Feature-Vector AVP.



Korhonen, et al.          Expires June 25, 2015                [Page 12]

Internet-Draft                    DOIC                     December 2014


   An OC-Supported-Features AVP in answer messages indicates there is a
   reporting node for the transaction.  The reacting node MAY take
   action, for example creating state for some stateful abatement
   algorithm, based on the features indicated in the OC-Feature-Vector
   AVP.

      Note: The loss abatement algorithm does not require stateful
      behavior when there is no active overload report.

5.1.2.  Reporting Node Behavior

   Upon receipt of a request message, a reporting node determines if
   there is a reacting node for the transaction based on the presence of
   the OC-Supported-Features AVP in the request message.

   If the request message contains an OC-Supported-Features AVP then a
   reporting node MUST include the OC-Supported-Features AVP in the
   answer message for that transaction.

   A reporting node MUST NOT include the OC-Supported-Features AVP, OC-
   OLR AVP or any other overload control AVPs defined in extension
   drafts in response messages for transactions where the request
   message does not include the OC-Supported-Features AVP.  Lack of the
   OC-Supported-Features AVP in the request message indicates that there
   is no reacting node for the transaction.

   A reporting node knows what overload control functionality is
   supported by the reacting node based on the content or absence of the
   OC-Feature-Vector AVP within the OC-Supported-Features AVP in the
   request message.

   A reporting node MUST indicate support for one and only one abatement
   algorithm in the OC-Feature-Vector AVP.  The abatement algorithm
   selected MUST indicate the abatement algorithm the reporting node
   wants the reacting node to use when the reporting node enters an
   overload condition.

   The abatement algorithm selected MUST be from the set of abatement
   algorithms contained in the request message's OC-Feature-Vector AVP.

   A reporting node that selects the loss algorithm may do so by
   including the OC-Feature-Vector AVP with an explicit indication of
   the loss algorithm, or it MAY omit OC-Feature-Vector.  If it selects
   a different algorithm, it MUST include the OC-Feature-Vector AVP with
   an explicit indication of the selected algorithm.






Korhonen, et al.          Expires June 25, 2015                [Page 13]

Internet-Draft                    DOIC                     December 2014


   A reporting node MUST NOT change the selected algorithm during the
   period of time that starts when entering an overload condition and
   ends when the associated OCS becomes invalid in all reacting nodes.

   The reporting node MAY change the overload abatement algorithm
   indicated in the OC-Supported-Features AVP at any time as long as no
   previously sent OLRs may be active.

   The reporting node SHOULD indicate support for other DOIC features
   defined in extension drafts that it supports and that apply to the
   transaction.

      Note: Not all DOIC features will apply to all Diameter
      applications or deployment scenarios.  The features included in
      the OC-Feature-Vector AVP are based on local reporting node
      policy.

5.1.3.  Agent Behavior

   Diameter Agents that support DOIC MAY ensure that all messages
   relayed by the agent contain the OC-Supported-Features AVP.

   A Diameter Agent SHOULD take on reacting node behavior for Diameter
   endpoints that do not support the DOIC solution.  A Diameter Agent
   detects that a Diameter endpoint does not support DOIC reacting node
   behavior when there is no OC-Supported-Features AVP in a request
   message.

   For a Diameter Agent to be a reacting node for a non supporting
   Diameter endpoint, the Diameter Agent MUST include the OC-Supported-
   Features AVP in request messages it relays that do not contain the
   OC-Supported-Features AVP.

   A Diameter Agent MAY take on reporting node behavior for Diameter
   endpoints that do not support the DOIC solution.  The Diameter Agent
   MUST have visibility to all traffic destined for the non supporting
   host in order to become the reporting node for the Diameter endpoint.
   A Diameter Agent detects that a Diameter endpoint does not support
   DOIC reporting node behavior when there is no OC-Supported-Features
   AVP in an answer message for a transaction that contained the OC-
   Supported-Features AVP in the request message.

   If a request already has the OC-Supported-Features AVP, a Diameter
   agent MAY modify it to reflect the features appropriate for the
   transaction.  Otherwise, the agent relays the OC-Supported-Features
   AVP without change.





Korhonen, et al.          Expires June 25, 2015                [Page 14]

Internet-Draft                    DOIC                     December 2014


      For instance, if the agent supports a superset of the features
      reported by the reacting node then the agent might choose, based
      on local policy, to advertise that superset of features to the
      reporting node.

   If the Diameter Agent changes the OC-Supported-Features AVP in a
   request message then it is likely it will also need to modify the OC-
   Supported-Features AVP in the answer message for the transaction.  A
   Diameter Agent MAY modify the OC-Supported-Features AVP carried in
   answer messages.

   When making changes to the OC-Supported-Features AVP the Diameter
   Agent needs to ensure that it does not introduce incorrect behavior
   for either the upstream or downstream DOIC nodes..

5.2.  Overload Report Processing

5.2.1.  Overload Control State

   Both reacting and reporting nodes maintain Overload Control State
   (OCS) for active overload conditions.  The following sections define
   behavior associated with that OCS.

5.2.1.1.  Overload Control State for Reacting Nodes

   A reacting node SHOULD maintain the following OCS per supported
   Diameter application:

   o  A host-type OCS entry for each Destination-Host to which it sends
      host-type requests and

   o  A realm-type OCS entry for each Destination-Realm to which it
      sends realm-type requests.

   A host-type OCS entry is identified by the pair of application-id and
   the node's DiameterIdentity.

   A realm-type OCS entry is identified by the pair of application-id
   and realm.

   The host-type and realm-type OCS entries MAY include the following
   information (the actual information stored is an implementation
   decision):

   o  Sequence number (as received in OC-OLR)






Korhonen, et al.          Expires June 25, 2015                [Page 15]

Internet-Draft                    DOIC                     December 2014


   o  Time of expiry (derived from OC-Validity-Duration AVP received in
      the OC-OLR AVP and time of reception of the message carrying OC-
      OLR AVP)

   o  Selected Abatement Algorithm (as received in the OC-Supported-
      Features AVP)

   o  Abatement Algorithm specific input data (as received in the OC-OLR
      AVP, for example, OC-Reduction-Percentage for the Loss abatement
      algorithm)

5.2.1.2.  Overload Control State for Reporting Nodes

   A reporting node SHOULD maintain OCS entries per supported Diameter
   application, per supported (and eventually selected) Abatement
   Algorithm and per report-type.

   An OCS entry is identified by the tuple of Application-Id, Report-
   Type and Abatement Algorithm and MAY include the following
   information (the actual information stored is an implementation
   decision):

   o  Sequence number

   o  Validity Duration

   o  Expiration Time

   o  Algorithm specific input data (for example, the Reduction
      Percentage for the Loss Abatement Algorithm)

5.2.1.3.  Reacting Node Maintenance of Overload Control State

   When a reacting node receives an OC-OLR AVP, it MUST determine if it
   is for an existing or new overload condition.

      Note: For the remainder of this section the term OLR refers to the
      combination of the contents of the received OC-OLR AVP and the
      abatement algorithm indicated in the received OC-Supported-
      Features AVP.

   When receiving an answer message with multiple OLRs of different
   supported report types, a reacting node MUST process each received
   OLR.

   When receiving an answer message with multiple OLRs and multiple of
   the OLRs are of the same supported report types, a reacting node
   SHOULD ignore the duplicated OLRs.



Korhonen, et al.          Expires June 25, 2015                [Page 16]

Internet-Draft                    DOIC                     December 2014


   A reacting node SHOULD ignore an OC-OLR with a OC-Report-Type AVP
   that contains an unrecognized value.

   The OLR is for an existing overload condition if a reacting node has
   an OCS that matches the received OLR.

   For a host-report this means it matches the application-id and the
   host's DiameterIdentity in an existing host OCS entry.

   For a realm-report this means it matches the application-id and the
   realm in an existing realm OCS entry.

   If the OLR is for an existing overload condition then a reacting node
   MUST determine if the OLR is a retransmission or an update to the
   existing OLR.

   If the sequence number for the received OLR is greater than the
   sequence number stored in the matching OCS entry then a reacting node
   MUST update the matching OCS entry.

   If the sequence number for the received OLR is less than or equal to
   the sequence number in the matching OCS entry then a reacting node
   MUST silently ignore the received OLR.  The matching OCS MUST NOT be
   updated in this case.

   If the received OLR is for a new overload condition then a reacting
   node MUST generate a new OCS entry for the overload condition.

   For a host-report this means a reacting node creates on OCS entry
   with the application-id in the received message and DiameterIdentity
   of the Origin-Host in the received message.

      Note: This solution assumes that the Origin-Host AVP in the answer
      message included by the reporting node is not changed along the
      path to the reacting node.

   For a realm-report this means a reacting node creates on OCS entry
   with the application-id in the received message and realm of the
   Origin-Realm in the received message.

   If the received OLR contains a validity duration of zero ("0") then a
   reacting node MUST update the OCS entry as being expired.

      Note: It is not necessarily appropriate to delete the OCS entry,
      as there is recommended behavior that the reacting node slowly
      returns to full traffic when ending an overload abatement period.





Korhonen, et al.          Expires June 25, 2015                [Page 17]

Internet-Draft                    DOIC                     December 2014


   The reacting node does not delete an OCS when receiving an answer
   message that does not contain an OC-OLR AVP (i.e. absence of OLR
   means "no change").

5.2.1.4.  Reporting Node Maintenance of Overload Control State

   A reporting node SHOULD create a new OCS entry when entering an
   overload condition.

      Note: If a reporting node knows through absence of the OC-
      Supported-Features AVP in received messages that there are no
      reacting nodes supporting DOIC then the reporting node can choose
      to not create OCS entries.

   When generating a new OCS entry the sequence number SHOULD be set to
   zero ("0").

   When generating sequence numbers for new overload conditions, the new
   sequence number MUST be greater than any sequence number in an active
   (unexpired) overload report for the same application and report-type
   previously sent by the reporting node.  This property MUST hold over
   a reboot of the reporting node.

      Note: One way of addressing this over a reboot of a reporting node
      is to use a time stamp for the first overload condition that
      occurs after the report and to start using sequence numbers of
      zero for subsequent overload conditions.

   A reporting node MUST update an OCS entry when it needs to adjust the
   validity duration of the overload condition at reacting nodes.

      For instance, if a reporting node wishes to instruct reacting
      nodes to continue overload abatement for a longer period of time
      than originally communicated.  This also applies if the reporting
      node wishes to shorten the period of time that overload abatement
      is to continue.

   A reporting node MUST NOT update the abatement algorithm in an active
   OCS entry.

   A reporting node MUST update an OCS entry when it wishes to adjust
   any abatement algorithm specific parameters, including, for example,
   the reduction percentage used for the Loss abatement algorithm.

      For instance, if a reporting node wishes to change the reduction
      percentage either higher, if the overload condition has worsened,
      or lower, if the overload condition has improved, then the
      reporting node would update the appropriate OCS entry.



Korhonen, et al.          Expires June 25, 2015                [Page 18]

Internet-Draft                    DOIC                     December 2014


   A reporting node MUST increment the sequence number associated with
   the OCS entry anytime the contents of the OCS entry are changed.
   This will result in a new sequence number being sent to reacting
   nodes, instructing reacting nodes to process the OC-OLR AVP.

   A reporting node SHOULD update an OCS entry with a validity duration
   of zero ("0") when the overload condition ends.

      Note: If a reporting node knows that the OCS entries in the
      reacting nodes are near expiration then the reporting node might
      decide not to send an OLR with a validity duration of zero.

   A reporting node MUST keep an OCS entry with a validity duration of
   zero ("0") for a period of time long enough to ensure that any non-
   expired reacting node's OCS entry created as a result of the overload
   condition in the reporting node is deleted.

5.2.2.  Reacting Node Behavior

   When a reacting node sends a request it MUST determine if that
   request matches an active OCS.

   If the request matches an active OCS then the reacting node MUST use
   the overload abatement algorithm indicated in the OCS to determine if
   the request is to receive overload abatement treatment.

   For the Loss abatement algorithm defined in this specification, see
   Section 6 for the overload abatement algorithm logic applied.

   If the overload abatement algorithm selects the request for overload
   abatement treatment then the reacting node MUST apply overload
   abatement treatment on the request.  The abatement treatment applied
   depends on the context of the request.

   If diversion abatement treatment is possible (i.e. a different path
   for the request can be selected where the overloaded node is not part
   of the different path), then the reacting node SHOULD apply diversion
   abatement treatment to the request.  Otherwise the reacting node
   SHOULD apply throttling abatement treatment to the request.

   If the overload abatement treatment results in throttling of the
   request and if the reacting node is an agent then the agent MUST send
   an appropriate error as defined in Section 8.

   Diameter endpoints that throttle requests need to do so according to
   the rules of the client application.  Those rules will vary by
   application, and are beyond the scope of this document.




Korhonen, et al.          Expires June 25, 2015                [Page 19]

Internet-Draft                    DOIC                     December 2014


   In the case that the OCS entry indicated no traffic was to be sent to
   the overloaded entity and the validity duration expires then overload
   abatement associated with the overload report MUST be ended in a
   controlled fashion.

5.2.3.  Reporting Node Behavior

   If there is an active OCS entry then a reporting node SHOULD include
   the OC-OLR AVP in all answers to requests that contain the OC-
   Supported-Features AVP and that match the active OCS entry.

      Note: A request matches if the application-id in the request
      matches the application-id in any active OCS entry and if the
      report-type in the OCS entry matches a report-type supported by
      the reporting node as indicated in the OC-Supported-Features AVP.

   The contents of the OC-OLR AVP depend on the selected algorithm.

   A reporting node MAY choose to not resend an overload report to a
   reacting node if it can guarantee that this overload report is
   already active in the reacting node.

      Note: In some cases (e.g. when there are one or more agents in the
      path between reporting and reacting nodes, or when overload
      reports are discarded by reacting nodes) a reporting node may not
      be able to guarantee that the reacting node has received the
      report.

   A reporting node MUST NOT send overload reports of a type that has
   not been advertised as supported by the reacting node.

      Note: A reacting node implicitly advertises support for the host
      and realm report types by including the OC-Supported-Features AVP
      in the request.  Support for other report types will be explicitly
      indicated by new feature bits in the OC-Feature-Vector AVP.

   A reporting node SHOULD explicitly indicate the end of an overload
   occurrence by sending a new OLR with OC-Validity-Duration set to a
   value of zero ("0").  The reporting node SHOULD ensure that all
   reacting nodes receive the updated overload report.

   A reporting node MAY rely on the OC-Validity-Duration AVP values for
   the implicit overload control state cleanup on the reacting node.

      Note: All OLRs sent have an expiration time calculated by adding
      the validity-duration contained in the OLR to the time the message
      was sent.  Transit time for the OLR can be safely ignored.  The
      reporting node can ensure that all reacting nodes have received



Korhonen, et al.          Expires June 25, 2015                [Page 20]

Internet-Draft                    DOIC                     December 2014


      the OLR by continuing to send it in answer messages until the
      expiration time for all OLRs sent for that overload condition have
      expired.

   When a reporting node sends an OLR, it effectively delegates any
   necessary throttling to downstream nodes.  If the reporting node also
   locally throttles the same set of messages, the overall number of
   throttled requests may be higher than intended.  Therefore, before
   applying local message throttling, a reporting node needs to check if
   these messages match existing OCS entries, indicating that these
   messages have survived throttling applied by downstream nodes that
   have received the related OLR.

   However, even if the set of messages match existing OCS entries, the
   reporting node can still apply other abatement methods such as
   diversion.  The reporting node might also need to throttle requests
   for reasons other than overload.  For example, an agent or server
   might have a configured rate limit for each client, and throttle
   requests that exceed that limit, even if such requests had already
   been candidates for throttling by downstream nodes.  The reporting
   node also has the option to send new OLRs requesting greater
   reductions in traffic, reducing the need for local throttling.

   A reporting node SHOULD decrease requested overload abatement
   treatment in a controlled fashion to avoid oscillations in traffic.

      For example, it might wait some period of time after overload ends
      before terminating the OLR, or it might send a series of OLRs
      indicating progressively less overload severity.

5.3.  Protocol Extensibility

   The DOIC solution can be extended.  Types of potential extensions
   include new traffic abatement algorithms, new report types or other
   new functionality.

   When defining a new extension that requires new normative behavior,
   the specification MUST define a new feature for the OC-Feature-
   Vector.  This feature bit is used to communicate support for the new
   feature.

   The extension MAY define new AVPs for use in DOIC Capability
   Announcement and for use in DOIC Overload reporting.  These new AVPs
   SHOULD be defined to be extensions to the OC-Supported-Features or
   OC-OLR AVPs defined in this document.






Korhonen, et al.          Expires June 25, 2015                [Page 21]

Internet-Draft                    DOIC                     December 2014


   [RFC6733] defined Grouped AVP extension mechanisms apply.  This
   allows, for example, defining a new feature that is mandatory to be
   understood even when piggybacked on an existing application.

   When defining new report type values, the corresponding specification
   MUST define the semantics of the new report types and how they affect
   the OC-OLR AVP handling.

   The OC-OLR AVP can be expanded with optional sub-AVPs only if a
   legacy DOIC implementation can safely ignore them without breaking
   backward compatibility for the given OC-Report-Type AVP value.

   Documents that introduce new report types MUST describe any
   limitations on their use across non-supporting agents.

   As with any Diameter specification, RFC6733 requires all new AVPs to
   be registered with IANA.  See Section 9 for the required procedures.
   New features (feature bits in the OC-Feature-Vector AVP) and report
   types (in the OC-Report-Type AVP) MUST be registered with IANA.

6.  Loss Algorithm

   This section documents the Diameter overload loss abatement
   algorithm.

6.1.  Overview

   The DOIC specification supports the ability for multiple overload
   abatement algorithms to be specified.  The abatement algorithm used
   for any instance of overload is determined by the Diameter Overload
   Capability Announcement process documented in Section 5.1.

   The loss algorithm described in this section is the default algorithm
   that must be supported by all Diameter nodes that support DOIC.

   The loss algorithm is designed to be a straightforward and stateless
   overload abatement algorithm.  It is used by reporting nodes to
   request a percentage reduction in the amount of traffic sent.  The
   traffic impacted by the requested reduction depends on the type of
   overload report.

   Reporting nodes request the stateless reduction of the number of
   requests by an indicated percentage.  This percentage reduction is in
   comparison to the number of messages the node otherwise would send,
   regardless of how many requests the node might have sent in the past.

   From a conceptual level, the logic at the reacting node could be
   outlined as follows.



Korhonen, et al.          Expires June 25, 2015                [Page 22]

Internet-Draft                    DOIC                     December 2014


   1.  An overload report is received and the associated OCS is either
       saved or updated (if required) by the reacting node.

   2.  A new Diameter request is generated by the application running on
       the reacting node.

   3.  The reacting node determines that an active overload report
       applies to the request, as indicated by the corresponding OCS
       entry.

   4.  The reacting node determines if overload abatement treatment
       should be applied to the request.  One approach that could be
       taken for each request is to select a random number between 1 and
       100.  If the random number is less than or equal to the indicated
       reduction percentage then the request is given abatement
       treatment, otherwise the request is given normal routing
       treatment.

6.2.  Reporting Node Behavior

   The method a reporting node uses to determine the amount of traffic
   reduction required to address an overload condition is an
   implementation decision.

   When a reporting node that has selected the loss abatement algorithm
   determines the need to request a reduction in traffic, it includes an
   OC-OLR AVP in answer messages as described in Section 5.2.3.

   When sending the OC-OLR AVP, the reporting node MUST indicate a
   percentage reduction in the OC-Reduction-Percentage AVP.

   The reporting node MAY change the reduction percentage in subsequent
   overload reports.  When doing so the reporting node must conform to
   overload report handing specified in Section 5.2.3.

6.3.  Reacting Node Behavior

   The method a reacting node uses to determine which request messages
   are given abatement treatment is an implementation decision.

   When receiving an OC-OLR in an answer message where the algorithm
   indicated in the OC-Supported-Features AVP is the loss algorithm, the
   reacting node MUST apply abatement treatment to the requested
   percentage of request messages sent.

      Note: The loss algorithm is a stateless algorithm.  As a result,
      the reacting node does not guarantee that there will be an
      absolute reduction in traffic sent.  Rather, it guarantees that



Korhonen, et al.          Expires June 25, 2015                [Page 23]

Internet-Draft                    DOIC                     December 2014


      the requested percentage of new requests will be given abatement
      treatment.

   When applying overload abatement treatment for the loss abatement
   algorithm, the reacting node MUST abate the requested percentage of
   requests that would have otherwise been sent to the reporting host or
   realm.

   If reacting node comes out of the 100 percent traffic reduction as a
   result of the overload report timing out, the following procedures
   are RECOMMENDED to be applied.  The reacting node sending the traffic
   should be conservative and, for example, first send "probe" messages
   to learn the overload condition of the overloaded node before
   converging to any traffic amount/rate decided by the sender.  Similar
   concerns apply in all cases when the overload report times out unless
   the previous overload report stated 0 percent reduction.

      The goal of this behavior is to reduce the probability of overload
      condition thrashing where an immediate transition from 100%
      reduction to 0% reduction results in the reporting node moving
      quickly back into an overload condition.

   If the reacting node does not receive an OLR in answers received from
   the formerly overloaded node then the reacting node SHOULD slowly
   increase the rate of traffic sent to the overloaded node.

7.  Attribute Value Pairs

   This section describes the encoding and semantics of the Diameter
   Overload Indication Attribute Value Pairs (AVPs) defined in this
   document.

7.1.  OC-Supported-Features AVP

   The OC-Supported-Features AVP (AVP code TBD1) is of type Grouped and
   serves two purposes.  First, it announces a node's support for the
   DOIC solution in general.  Second, it contains the description of the
   supported DOIC features of the sending node.  The OC-Supported-
   Features AVP MUST be included in every Diameter request message a
   DOIC supporting node sends.

      OC-Supported-Features ::= < AVP Header: TBD1 >
                                [ OC-Feature-Vector ]
                              * [ AVP ]







Korhonen, et al.          Expires June 25, 2015                [Page 24]

Internet-Draft                    DOIC                     December 2014


7.2.  OC-Feature-Vector AVP

   The OC-Feature-Vector AVP (AVP code TBD2) is of type Unsigned64 and
   contains a 64 bit flags field of announced capabilities of a DOIC
   node.  The value of zero (0) is reserved.

   The OC-Feature-Vector sub-AVP is used to announce the DOIC features
   supported by the DOIC node, in the form of a flag-bits field in which
   each bit announces one feature or capability supported by the node.
   The absence of the OC-Feature-Vector AVP in request messages
   indicates that only the default traffic abatement algorithm described
   in this specification is supported.  The absence of the OC- Feature-
   Vector AVP in answer messages indicates that the default traffic
   abatement algorithm described in this specification is selected
   (while other traffic abatement algorithms may be supported), and no
   features other than abatement algorithms are supported.

   The following capabilities are defined in this document:

   OLR_DEFAULT_ALGO (0x0000000000000001)

      When this flag is set by the a DOIC reacting node it means that
      the default traffic abatement (loss) algorithm is supported.  When
      this flag is set by a DOIC reporting node it means that the loss
      algorithm will be used for requested overload abatement.

7.3.  OC-OLR AVP

   The OC-OLR AVP (AVP code TBD3) is of type Grouped and contains the
   information necessary to convey an overload report on an overload
   condition at the reporting node.  The application the OC-OLR AVP
   applies to is the same as the Application-Id found in the Diameter
   message header.  The host or realm the OC-OLR AVP concerns is
   determined from the Origin-Host AVP and/or Origin-Realm AVP found in
   the encapsulating Diameter command.  The OC-OLR AVP is intended to be
   sent only by a reporting node.

      OC-OLR ::= < AVP Header: TBD2 >
                 < OC-Sequence-Number >
                 < OC-Report-Type >
                 [ OC-Reduction-Percentage ]
                 [ OC-Validity-Duration ]
               * [ AVP ]








Korhonen, et al.          Expires June 25, 2015                [Page 25]

Internet-Draft                    DOIC                     December 2014


7.4.  OC-Sequence-Number AVP

   The OC-Sequence-Number AVP (AVP code TBD4) is of type Unsigned64.
   Its usage in the context of overload control is described in
   Section 5.2.

   From the functionality point of view, the OC-Sequence-Number AVP is
   used as a non-volatile increasing counter for a sequence of overload
   reports between two DOIC nodes for the same overload occurrence.
   Sequence numbers are treated in a uni-directional manner, i.e. two
   sequence numbers on each direction between two DOIC nodes are not
   related or correlated.

7.5.  OC-Validity-Duration AVP

   The OC-Validity-Duration AVP (AVP code TBD5) is of type Unsigned32
   and indicates in milliseconds the validity time of the overload
   report.  The number of milliseconds is measured after reception of
   the first OC-OLR AVP with a given value of OC-Sequence-Number AVP.
   The default value for the OC-Validity-Duration AVP is 30000 (i.e.; 30
   seconds).  When the OC-Validity-Duration AVP is not present in the
   OC-OLR AVP, the default value applies.

7.6.  OC-Report-Type AVP

   The OC-Report-Type AVP (AVP code TBD6) is of type Enumerated.  The
   value of the AVP describes what the overload report concerns.  The
   following values are initially defined:

   HOST_REPORT 0  The overload report is for a host.  Overload abatement
      treatment applies to host-routed requests.

   REALM_REPORT 1  The overload report is for a realm.  Overload
      abatement treatment applies to realm-routed requests.

7.7.  OC-Reduction-Percentage AVP

   The OC-Reduction-Percentage AVP (AVP code TBD7) is of type Unsigned32
   and describes the percentage of the traffic that the sender is
   requested to reduce, compared to what it otherwise would send.  The
   OC-Reduction-Percentage AVP applies to the default (loss) algorithm
   specified in this specification.  However, the AVP can be reused for
   future abatement algorithms, if its semantics fit into the new
   algorithm.

   The value of the Reduction-Percentage AVP is between zero (0) and one
   hundred (100).  Values greater than 100 are ignored.  The value of
   100 means that all traffic is to be throttled, i.e. the reporting



Korhonen, et al.          Expires June 25, 2015                [Page 26]

Internet-Draft                    DOIC                     December 2014


   node is under a severe load and ceases to process any new messages.
   The value of 0 means that the reporting node is in a stable state and
   has no need for the reacting node to apply any traffic abatement.

7.8.  Attribute Value Pair flag rules

                                                         +---------+
                                                         |AVP flag |
                                                         |rules    |
                                                         +----+----+
                              AVP   Section              |    |MUST|
       Attribute Name         Code  Defined  Value Type  |MUST| NOT|
      +--------------------------------------------------+----+----+
      |OC-Supported-Features  TBD1  6.1      Grouped     |    | V  |
      +--------------------------------------------------+----+----+
      |OC-Feature-Vector      TBD2  6.2      Unsigned64  |    | V  |
      +--------------------------------------------------+----+----+
      |OC-OLR                 TBD3  6.3      Grouped     |    | V  |
      +--------------------------------------------------+----+----+
      |OC-Sequence-Number     TBD4  6.4      Unsigned64  |    | V  |
      +--------------------------------------------------+----+----+
      |OC-Validity-Duration   TBD5  6.5      Unsigned32  |    | V  |
      +--------------------------------------------------+----+----+
      |OC-Report-Type         TBD6  6.6      Enumerated  |    | V  |
      +--------------------------------------------------+----+----+
      |OC-Reduction                                      |    |    |
      |  -Percentage          TBD7  6.7      Unsigned32  |    | V  |
      +--------------------------------------------------+----+----+


   As described in the Diameter base protocol [RFC6733], the M-bit usage
   for a given AVP in a given command may be defined by the application.

8.  Error Response Codes

   When a DOIC node rejects a Diameter request due to overload, the DOIC
   node MUST select an appropriate error response code.  This
   determination is made based on the probability of the request
   succeeding if retried on a different path.

   A reporting node rejecting a Diameter request due to an overload
   condition SHOULD send a DIAMETER_TOO_BUSY error response, if it can
   assume that the same request may succeed on a different path.

   If a reporting node knows or assumes that the same request will not
   succeed on a different path, DIAMETER_UNABLE_TO_COMPLY error response
   SHOULD be used.  Retrying would consume valuable resources during an
   occurrence of overload.



Korhonen, et al.          Expires June 25, 2015                [Page 27]

Internet-Draft                    DOIC                     December 2014


      For instance, if the request arrived at the reporting node without
      a Destination-Host AVP then the reporting node might determine
      that there is an alternative Diameter node that could successfully
      process the request and that retrying the transaction would not
      negatively impact the reporting node.  DIAMETER_TOO_BUSY would be
      sent in this case.

      If the request arrived at the reporting node with a Destination-
      Host AVP populated with its own Diameter identity then the
      reporting node can assume that retrying the request would result
      in it coming to the same reporting node.
      DIAMETER_UNABLE_TO_COMPLY would be sent in this case.

      A second example is when an agent that supports the DOIC solution
      is performing the role of a reacting node for a non supporting
      client.  Requests that are rejected as a result of DOIC throttling
      by the agent in this scenario would generally be rejected with a
      DIAMETER_UNABLE_TO_COMPLY response code.

9.  IANA Considerations

9.1.  AVP codes

   New AVPs defined by this specification are listed in Section 7.  All
   AVP codes are allocated from the 'Authentication, Authorization, and
   Accounting (AAA) Parameters' AVP Codes registry.

9.2.  New registries

   Two new registries are needed under the 'Authentication,
   Authorization, and Accounting (AAA) Parameters' registry.

   A new "Overload Control Feature Vector" registry is required.  The
   registry must contain the following:

      Feature Vector Value

      Specification - the specification that defines the new value.

   See Section 7.2 for the initial Feature Vector Value in the registry.
   This specification is the specification defining the value.  New
   values can be added into the registry using the Specification
   Required policy.  [RFC5226].

   A new "Overload Report Type" registry is required.  The registry must
   contain the following:

      Report Type Value



Korhonen, et al.          Expires June 25, 2015                [Page 28]

Internet-Draft                    DOIC                     December 2014


      Specification - the specification that defines the new value.

   See Section 7.6 for the initial assignment in the registry.  New
   types can be added using the Specification Required policy [RFC5226].

10.  Security Considerations

   DOIC gives Diameter nodes the ability to request that downstream
   nodes send fewer Diameter requests.  Nodes do this by exchanging
   overload reports that directly effect this reduction.  This exchange
   is potentially subject to multiple methods of attack, and has the
   potential to be used as a Denial-of-Service (DoS) attack vector.

   Overload reports may contain information about the topology and
   current status of a Diameter network.  This information is
   potentially sensitive.  Network operators may wish to control
   disclosure of overload reports to unauthorized parties to avoid its
   use for competitive intelligence or to target attacks.

   Diameter does not include features to provide end-to-end
   authentication, integrity protection, or confidentiality.  This may
   cause complications when sending overload reports between non-
   adjacent nodes.

10.1.  Potential Threat Modes

   The Diameter protocol involves transactions in the form of requests
   and answers exchanged between clients and servers.  These clients and
   servers may be peers, that is, they may share a direct transport
   (e.g.  TCP or SCTP) connection, or the messages may traverse one or
   more intermediaries, known as Diameter Agents.  Diameter nodes use
   TLS, DTLS, or IPsec to authenticate peers, and to provide
   confidentiality and integrity protection of traffic between peers.
   Nodes can make authorization decisions based on the peer identities
   authenticated at the transport layer.

   When agents are involved, this presents an effectively transitive
   trust model.  That is, a Diameter client or server can authorize an
   agent for certain actions, but it must trust that agent to make
   appropriate authorization decisions about its peers, and so on.
   Since confidentiality and integrity protection occurs at the
   transport layer, agents can read, and perhaps modify, any part of a
   Diameter message, including an overload report.

   There are several ways an attacker might attempt to exploit the
   overload control mechanism.  An unauthorized third party might inject
   an overload report into the network.  If this third party is upstream
   of an agent, and that agent fails to apply proper authorization



Korhonen, et al.          Expires June 25, 2015                [Page 29]

Internet-Draft                    DOIC                     December 2014


   policies, downstream nodes may mistakenly trust the report.  This
   attack is at least partially mitigated by the assumption that nodes
   include overload reports in Diameter answers but not in requests.
   This requires an attacker to have knowledge of the original request
   in order to construct an answer.  Such an answer would also need to
   arrive at a Diameter node via a protected transport connection.
   Therefore, implementations MUST validate that an answer containing an
   overload report is a properly constructed response to a pending
   request prior to acting on the overload report, and that the answer
   was received via an appropriate transport connection.

   A similar attack involves a compromised but otherwise authorized node
   that sends an inappropriate overload report.  For example, a server
   for the realm "example.com" might send an overload report indicating
   that a competitor's realm "example.net" is overloaded.  If other
   nodes act on the report, they may falsely believe that "example.net"
   is overloaded, effectively reducing that realm's capacity.
   Therefore, it's critical that nodes validate that an overload report
   received from a peer actually falls within that peer's responsibility
   before acting on the report or forwarding the report to other peers.
   For example, an overload report from a peer that applies to a realm
   not handled by that peer is suspect.

      This attack is partially mitigated by the fact that the
      application, as well as host and realm, for a given OLR is
      determined implicitly by respective AVPs in the enclosing answer.
      If a reporting node modifies any of those AVPs, the enclosing
      transaction will also be affected.

10.2.  Denial of Service Attacks

   Diameter overload reports, especially realm-reports, can cause a node
   to cease sending some or all Diameter requests for an extended
   period.  This makes them a tempting vector for DoS attacks.
   Furthermore, since Diameter is almost always used in support of other
   protocols, a DoS attack on Diameter is likely to impact those
   protocols as well.  Therefore, Diameter nodes MUST NOT honor or
   forward OLRs received from peers that are not trusted to send them.

   An attacker might use the information in an OLR to assist in DoS
   attacks.  For example, an attacker could use information about
   current overload conditions to time an attack for maximum effect, or
   use subsequent overload reports as a feedback mechanism to learn the
   results of a previous or ongoing attack.  Operators need the ability
   to ensure that OLRs are not leaked to untrusted parties.






Korhonen, et al.          Expires June 25, 2015                [Page 30]

Internet-Draft                    DOIC                     December 2014


10.3.  Non-Compliant Nodes

   In the absence of an overload control mechanism, Diameter nodes need
   to implement strategies to protect themselves from floods of
   requests, and to make sure that a disproportionate load from one
   source does not prevent other sources from receiving service.  For
   example, a Diameter server might throttle a certain percentage of
   requests from sources that exceed certain limits.  Overload control
   can be thought of as an optimization for such strategies, where
   downstream nodes never send the excess requests in the first place.
   However, the presence of an overload control mechanism does not
   remove the need for these other protection strategies.

   When a Diameter node sends an overload report, it cannot assume that
   all nodes will comply, even if they indicate support for DOIC.  A
   non-compliant node might continue to send requests with no reduction
   in load.  Such non-compliance could be done accidentally, or
   maliciously to gain an unfair advantage over compliant nodes.
   Requirement 28 [RFC7068] indicates that the overload control solution
   cannot assume that all Diameter nodes in a network are trusted, and
   that malicious nodes not be allowed to take advantage of the overload
   control mechanism to get more than their fair share of service.

10.4.  End-to End-Security Issues

   The lack of end-to-end integrity features makes it difficult to
   establish trust in overload reports received from non-adjacent nodes.
   Any agents in the message path may insert or modify overload reports.
   Nodes must trust that their adjacent peers perform proper checks on
   overload reports from their peers, and so on, creating a transitive-
   trust requirement extending for potentially long chains of nodes.
   Network operators must determine if this transitive trust requirement
   is acceptable for their deployments.  Nodes supporting Diameter
   overload control MUST give operators the ability to select which
   peers are trusted to deliver overload reports, and whether they are
   trusted to forward overload reports from non-adjacent nodes.  DOIC
   nodes MUST strip DOIC AVPs from messages received from peers that are
   not trusted for DOIC purposes.

   The lack of end-to-end confidentiality protection means that any
   Diameter agent in the path of an overload report can view the
   contents of that report.  In addition to the requirement to select
   which peers are trusted to send overload reports, operators MUST be
   able to select which peers are authorized to receive reports.  A node
   MUST NOT send an overload report to a peer not authorized to receive
   it.  Furthermore, an agent MUST remove any overload reports that
   might have been inserted by other nodes before forwarding a Diameter
   message to a peer that is not authorized to receive overload reports.



Korhonen, et al.          Expires June 25, 2015                [Page 31]

Internet-Draft                    DOIC                     December 2014


      A DOIC node cannot always automatically detect that a peer also
      supports DOIC.  For example, a node might have a peer that is a
      non-supporting agent.  If nodes on the other side of that agent
      send OC-Supported-Features AVPs, the agent is likely to forward
      them as unknown AVPs.  Messages received across the non-supporting
      agent may be indistinguishable from messages received across a
      DOIC supporting agent, giving the false impression that the non-
      supporting agent actually supports DOIC.  This complicates the
      transitive-trust nature of DOIC.  Operators need to be careful to
      avoid situations where a non-supporting agent is mistakenly
      trusted to enforce DOIC related authorization policies.

   At the time of this writing, the DIME working group is studying
   requirements for adding end-to-end security features
   [I-D.ietf-dime-e2e-sec-req] to Diameter.  These features, when they
   become available, might make it easier to establish trust in non-
   adjacent nodes for overload control purposes.  Readers should be
   reminded, however, that the overload control mechanism encourages
   Diameter agents to modify AVPs in, or insert additional AVPs into,
   existing messages that are originated by other nodes.  If end-to-end
   security is enabled, there is a risk that such modification could
   violate integrity protection.  The details of using any future
   Diameter end-to-end security mechanism with overload control will
   require careful consideration, and are beyond the scope of this
   document.

11.  Contributors

   The following people contributed substantial ideas, feedback, and
   discussion to this document:

   o  Eric McMurry

   o  Hannes Tschofenig

   o  Ulrich Wiehe

   o  Jean-Jacques Trottin

   o  Maria Cruz Bartolome

   o  Martin Dolly

   o  Nirav Salot

   o  Susan Shishufeng





Korhonen, et al.          Expires June 25, 2015                [Page 32]

Internet-Draft                    DOIC                     December 2014


12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC6733]  Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
              "Diameter Base Protocol", RFC 6733, October 2012.

12.2.  Informative References

   [Cx]       3GPP, , "ETSI TS 129 229 V11.4.0", August 2013.

   [I-D.ietf-dime-e2e-sec-req]
              Tschofenig, H., Korhonen, J., Zorn, G., and K. Pillay,
              "Diameter AVP Level Security: Scenarios and Requirements",
              draft-ietf-dime-e2e-sec-req-01 (work in progress), October
              2013.

   [PCC]      3GPP, , "ETSI TS 123 203 V11.12.0", December 2013.

   [RFC4006]  Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
              Loughney, "Diameter Credit-Control Application", RFC 4006,
              August 2005.

   [RFC7068]  McMurry, E. and B. Campbell, "Diameter Overload Control
              Requirements", RFC 7068, November 2013.

   [S13]      3GPP, , "ETSI TS 129 272 V11.9.0", December 2012.

Appendix A.  Issues left for future specifications

   The base solution for the overload control does not cover all
   possible use cases.  A number of solution aspects were intentionally
   left for future specification and protocol work.  The following sub-
   sections define some of the potential extensions to the DOIC
   solution.

A.1.  Additional traffic abatement algorithms

   This specification describes only means for a simple loss based
   algorithm.  Future algorithms can be added using the designed
   solution extension mechanism.  The new algorithms need to be



Korhonen, et al.          Expires June 25, 2015                [Page 33]

Internet-Draft                    DOIC                     December 2014


   registered with IANA.  See Sections 7.1 and 9 for the required IANA
   steps.

A.2.  Agent Overload

   This specification focuses on Diameter endpoint (server or client)
   overload.  A separate extension will be required to outline the
   handling of the case of agent overload.

A.3.  New Error Diagnostic AVP

   This specification indicates the use of existing error messages when
   nodes reject requests due to overload.  The DIME working group is
   considering defining additional error codes or AVPs to indicate that
   overload was the reason for the rejection of the message.

Appendix B.  Deployment Considerations

   Non Supporting Agents

      Due to the way that realm-routed requests are handled in Diameter
      networks with the server selection for the request done by an
      agent, network operators should enable DOIC at agents that perform
      server selection first.

   Topology Hiding Interactions

      There exist proxies that implement what is referred to as Topology
      Hiding.  This can include cases where the agent modifies the
      Origin-Host in answer messages.  The behavior of the DOIC solution
      is not well understood when this happens.  As such, the DOIC
      solution does not address this scenario.

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 3GPP has adopted an early version of this document as normative
   references 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 the 3GPP for the completion of the
   release 12 protocol work by the end of 2014.  The deferred work
   includes the following:



Korhonen, et al.          Expires June 25, 2015                [Page 34]

Internet-Draft                    DOIC                     December 2014


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



Korhonen, et al.          Expires June 25, 2015                [Page 35]

Internet-Draft                    DOIC                     December 2014


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.






Korhonen, et al.          Expires June 25, 2015                [Page 36]

Internet-Draft                    DOIC                     December 2014


   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



Korhonen, et al.          Expires June 25, 2015                [Page 37]

Internet-Draft                    DOIC                     December 2014


           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.





Korhonen, et al.          Expires June 25, 2015                [Page 38]

Internet-Draft                    DOIC                     December 2014


   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.





Korhonen, et al.          Expires June 25, 2015                [Page 39]

Internet-Draft                    DOIC                     December 2014


           *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 implementers 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.






Korhonen, et al.          Expires June 25, 2015                [Page 40]

Internet-Draft                    DOIC                     December 2014


   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.







Korhonen, et al.          Expires June 25, 2015                [Page 41]

Internet-Draft                    DOIC                     December 2014


   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.



Korhonen, et al.          Expires June 25, 2015                [Page 42]

Internet-Draft                    DOIC                     December 2014


           *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.  It 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



Korhonen, et al.          Expires June 25, 2015                [Page 43]

Internet-Draft                    DOIC                     December 2014


           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.







Korhonen, et al.          Expires June 25, 2015                [Page 44]

Internet-Draft                    DOIC                     December 2014


   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.



Appendix D.  Considerations for Applications Integrating the DOIC
             Solution

   This section outlines considerations to be taken into account when
   integrating the DOIC solution into Diameter applications.

D.1.  Application Classification

   The following is a classification of Diameter applications and
   request types.  This discussion is meant to document factors that
   play into decisions made by the Diameter identity responsible for
   handling overload reports.

   Section 8.1 of [RFC6733] defines two state machines that imply two
   types of applications, session-less and session-based applications.
   The primary difference between these types of applications is the
   lifetime of Session-Ids.

   For session-based applications, the Session-Id is used to tie
   multiple requests into a single session.



Korhonen, et al.          Expires June 25, 2015                [Page 45]

Internet-Draft                    DOIC                     December 2014


   The Credit-Control application defined in [RFC4006] is an example of
   a Diameter session-based application.

   In session-less applications, the lifetime of the Session-Id is a
   single Diameter transaction, i.e. the session is implicitly
   terminated after a single Diameter transaction and a new Session-Id
   is generated for each Diameter request.

   For the purposes of this discussion, session-less applications are
   further divided into two types of applications:

   Stateless Applications:

      Requests within a stateless application have no relationship to
      each other.  The 3GPP defined S13 application is an example of a
      stateless application [S13], where only a Diameter command is
      defined between a client and a server and no state is maintained
      between two consecutive transactions.

   Pseudo-Session Applications:

      Applications that do not rely on the Session-Id AVP for
      correlation of application messages related to the same session
      but use other session-related information in the Diameter requests
      for this purpose.  The 3GPP defined Cx application [Cx] is an
      example of a pseudo-session application.

   The handling of overload reports must take the type of application
   into consideration, as discussed in Appendix D.2.

D.2.  Application Type Overload Implications

   This section discusses considerations for mitigating overload
   reported by a Diameter entity.  This discussion focuses on the type
   of application.  Appendix D.3 discusses considerations for handling
   various request types when the target server is known to be in an
   overloaded state.

   These discussions assume that the strategy for mitigating the
   reported overload is to reduce the overall workload sent to the
   overloaded entity.  The concept of applying overload treatment to
   requests targeted for an overloaded Diameter entity is inherent to
   this discussion.  The method used to reduce offered load is not
   specified here but could include routing requests to another Diameter
   entity known to be able to handle them, or it could mean rejecting
   certain requests.  For a Diameter agent, rejecting requests will
   usually mean generating appropriate Diameter error responses.  For a
   Diameter client, rejecting requests will depend upon the application.



Korhonen, et al.          Expires June 25, 2015                [Page 46]

Internet-Draft                    DOIC                     December 2014


   For example, it could mean giving an indication to the entity
   requesting the Diameter service that the network is busy and to try
   again later.

   Stateless Applications:

      By definition there is no relationship between individual requests
      in a stateless application.  As a result, when a request is sent
      or relayed to an overloaded Diameter entity - either a Diameter
      Server or a Diameter Agent - the sending or relaying entity can
      choose to apply the overload treatment to any request targeted for
      the overloaded entity.

   Pseudo-Session Applications:

      For pseudo-session applications, there is an implied ordering of
      requests.  As a result, decisions about which requests towards an
      overloaded entity to reject could take the command code of the
      request into consideration.  This generally means that
      transactions later in the sequence of transactions should be given
      more favorable treatment than messages earlier in the sequence.
      This is because more work has already been done by the Diameter
      network for those transactions that occur later in the sequence.
      Rejecting them could result in increasing the load on the network
      as the transactions earlier in the sequence might also need to be
      repeated.

   Session-Based Applications:

      Overload handling for session-based applications must take into
      consideration the work load associated with setting up and
      maintaining a session.  As such, the entity sending requests
      towards an overloaded Diameter entity for a session-based
      application might tend to reject new session requests prior to
      rejecting intra-session requests.  In addition, session ending
      requests might be given a lower probability of being rejected as
      rejecting session ending requests could result in session status
      being out of sync between the Diameter clients and servers.
      Application designers that would decide to reject mid-session
      requests will need to consider whether the rejection invalidates
      the session and any resulting session cleanup procedures.

D.3.  Request Transaction Classification

   Independent Request:






Korhonen, et al.          Expires June 25, 2015                [Page 47]

Internet-Draft                    DOIC                     December 2014


      An independent request is not correlated to any other requests
      and, as such, the lifetime of the session-id is constrained to an
      individual transaction.

   Session-Initiating Request:

      A session-initiating request is the initial message that
      establishes a Diameter session.  The ACR message defined in
      [RFC6733] is an example of a session-initiating request.

   Correlated Session-Initiating Request:

      There are cases when multiple session-initiated requests must be
      correlated and managed by the same Diameter server.  It is notably
      the case in the 3GPP PCC architecture [PCC], where multiple
      apparently independent Diameter application sessions are actually
      correlated and must be handled by the same Diameter server.

   Intra-Session Request:

      An intra-session request is a request that uses the same Session-
      Id than the one used in a previous request.  An intra-session
      request generally needs to be delivered to the server that handled
      the session creating request for the session.  The STR message
      defined in [RFC6733] is an example of an intra-session request.

   Pseudo-Session Requests:

      Pseudo-session requests are independent requests and do not use
      the same Session-Id but are correlated by other session-related
      information contained in the request.  There exists Diameter
      applications that define an expected ordering of transactions.
      This sequencing of independent transactions results in a pseudo
      session.  The AIR, MAR and SAR requests in the 3GPP defined Cx
      [Cx] application are examples of pseudo-session requests.

D.4.  Request Type Overload Implications

   The request classes identified in Appendix D.3 have implications on
   decisions about which requests should be throttled first.  The
   following list of request treatment regarding throttling is provided
   as guidelines for application designers when implementing the
   Diameter overload control mechanism described in this document.  The
   exact behavior regarding throttling is a matter of local policy,
   unless specifically defined for the application.

   Independent Requests:




Korhonen, et al.          Expires June 25, 2015                [Page 48]

Internet-Draft                    DOIC                     December 2014


      Independent requests can generally be given equal treatment when
      making throttling decisions, unless otherwise indicated by
      application requirements or local policy.

   Session-Initiating Requests:

      Session-initiating requests often represent more work than
      independent or intra-session requests.  Moreover, session-
      initiating requests are typically followed by other session-
      related requests.  Since the main objective of the overload
      control is to reduce the total number of requests sent to the
      overloaded entity, throttling decisions might favor allowing
      intra-session requests over session-initiating requests.  In the
      absence of local policies or application specific requirements to
      the contrary, Individual session-initiating requests can be given
      equal treatment when making throttling decisions.

   Correlated Session-Initiating Requests:

      A Request that results in a new binding, where the binding is used
      for routing of subsequent session-initiating requests to the same
      server, represents more work load than other requests.  As such,
      these requests might be throttled more frequently than other
      request types.

   Pseudo-Session Requests:

      Throttling decisions for pseudo-session requests can take into
      consideration where individual requests fit into the overall
      sequence of requests within the pseudo session.  Requests that are
      earlier in the sequence might be throttled more aggressively than
      requests that occur later in the sequence.

   Intra-Session Requests:

      There are two types of intra-sessions requests, requests that
      terminate a session and the remainder of intra-session requests.
      Implementers and operators may choose to throttle session-
      terminating requests less aggressively in order to gracefully
      terminate sessions, allow cleanup of the related resources (e.g.
      session state) and avoid the need for additional intra-session
      requests.  Favoring session-termination requests may reduce the
      session management impact on the overloaded entity.  The default
      handling of other intra-session requests might be to treat them
      equally when making throttling decisions.  There might also be
      application level considerations whether some request types are
      favored over others.




Korhonen, et al.          Expires June 25, 2015                [Page 49]

Internet-Draft                    DOIC                     December 2014


Authors' Addresses

   Jouni Korhonen (editor)
   Broadcom
   Porkkalankatu 24
   Helsinki  FIN-00180
   Finland

   Email: jouni.nospam@gmail.com


   Steve Donovan (editor)
   Oracle
   7460 Warren Parkway
   Frisco, Texas  75034
   United States

   Email: srdonovan@usdonovans.com


   Ben Campbell
   Oracle
   7460 Warren Parkway
   Frisco, Texas  75034
   United States

   Email: ben@nostrum.com


   Lionel Morand
   Orange Labs
   38/40 rue du General Leclerc
   Issy-Les-Moulineaux Cedex 9  92794
   France

   Phone: +33145296257
   Email: lionel.morand@orange.com














Korhonen, et al.          Expires June 25, 2015                [Page 50]

--------------000005080501070401070001
Content-Type: text/html; charset=ISO-8859-1;
 name="Diff_ draft-ietf-dime-ovli-06.txt - draft-ietf-dime-ovli-06.txt.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="Diff_ draft-ietf-dime-ovli-06.txt - draft-ietf-dime-ovli-06.";
 filename*1="txt.html"


 
 
 
 
 
 
 
 
   
   
  Diff: draft-ietf-dime-ovli-06.txt - draft-ietf-dime-ovli-06.txt 
   
 
 
  
 
  
< draft-ietf-dime-ovli-06.txt   draft-ietf-dime-ovli-06.txt >
 
      
 

      
Diameter Maintenance and Extensions (DIME)              J. Korhonen, Ed. Diameter Maintenance and Extensions (DIME)              J. Korhonen, Ed.

      
Internet-Draft                                                  Broadcom Internet-Draft                                                  Broadcom

      
Intended status: Standards Track                         S. Donovan, Ed. Intended status: Standards Track                         S. Donovan, Ed.

      

      
Expires: June 18, 2015                                       B. Campbell Expires: June 25, 2015                                       B. Campbell

      
                                                                  Oracle                                                                   Oracle

      
                                                               L. Morand                                                                L. Morand

      
                                                             Orange Labs                                                              Orange Labs

      

      
                                                       December 15, 2014                                                        December 22, 2014

      
 

      
                Diameter Overload Indication Conveyance                 Diameter Overload Indication Conveyance

      
                      draft-ietf-dime-ovli-06.txt                       draft-ietf-dime-ovli-06.txt

      
 

      
Abstract Abstract

      
 

      
   This specification defines a base solution for Diameter overload    This specification defines a base solution for Diameter overload

      
   control, referred to as Diameter Overload Indication Conveyance    control, referred to as Diameter Overload Indication Conveyance

      
   (DOIC).    (DOIC).

      
 

      

      
Requirements 

      
 

      
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 

      
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 

      
   document are to be interpreted as described in RFC 2119 [RFC2119]. 

      
                                                                          

      
Status of This Memo Status of This Memo

      
 

      
   This Internet-Draft is submitted in full conformance with the    This Internet-Draft is submitted in full conformance with the

      
   provisions of BCP 78 and BCP 79.    provisions of BCP 78 and BCP 79.

      
 

      
   Internet-Drafts are working documents of the Internet Engineering    Internet-Drafts are working documents of the Internet Engineering

      
   Task Force (IETF).  Note that other groups may also distribute    Task Force (IETF).  Note that other groups may also distribute

      
   working documents as Internet-Drafts.  The list of current Internet-    working documents as Internet-Drafts.  The list of current Internet-

      
   Drafts is at http://datatracker.ietf.org/drafts/current/.    Drafts is at http://datatracker.ietf.org/drafts/current/.

      
 

      
   Internet-Drafts are draft documents valid for a maximum of six months    Internet-Drafts are draft documents valid for a maximum of six months

      
   and may be updated, replaced, or obsoleted by other documents at any    and may be updated, replaced, or obsoleted by other documents at any

      
   time.  It is inappropriate to use Internet-Drafts as reference    time.  It is inappropriate to use Internet-Drafts as reference

      
   material or to cite them other than as "work in progress."    material or to cite them other than as "work in progress."

      
 

      

      
   This Internet-Draft will expire on June 18, 2015.    This Internet-Draft will expire on June 25, 2015.

      
 

      
Copyright Notice Copyright Notice

      
 

      
   Copyright (c) 2014 IETF Trust and the persons identified as the    Copyright (c) 2014 IETF Trust and the persons identified as the

      
   document authors.  All rights reserved.    document authors.  All rights reserved.

      
 

      
   This document is subject to BCP 78 and the IETF Trust's Legal    This document is subject to BCP 78 and the IETF Trust's Legal

      
   Provisions Relating to IETF Documents    Provisions Relating to IETF Documents

      
   (http://trustee.ietf.org/license-info) in effect on the date of    (http://trustee.ietf.org/license-info) in effect on the date of

      
   publication of this document.  Please review these documents    publication of this document.  Please review these documents

      
   carefully, as they describe your rights and restrictions with respect    carefully, as they describe your rights and restrictions with respect

      
   to this document.  Code Components extracted from this document must    to this document.  Code Components extracted from this document must

      
   include Simplified BSD License text as described in Section 4.e of    include Simplified BSD License text as described in Section 4.e of

      
   the Trust Legal Provisions and are provided without warranty as    the Trust Legal Provisions and are provided without warranty as

      
   described in the Simplified BSD License.    described in the Simplified BSD License.

      
 

      
Table of Contents Table of Contents

      
 

      
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3

      
   2.  Terminology and Abbreviations . . . . . . . . . . . . . . . .   4    2.  Terminology and Abbreviations . . . . . . . . . . . . . . . .   4

      

      
   3.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   5    3.  Conventions Used in This Document . . . . . . . . . . . . . .   5

      
     3.1.  Piggybacking  . . . . . . . . . . . . . . . . . . . . . .   7    4.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   5

      
     3.2.  DOIC Capability Announcement  . . . . . . . . . . . . . .   8      4.1.  Piggybacking  . . . . . . . . . . . . . . . . . . . . . .   7

      
     3.3.  DOIC Overload Condition Reporting . . . . . . . . . . . .   9      4.2.  DOIC Capability Announcement  . . . . . . . . . . . . . .   7

      
     3.4.  DOIC Extensibility  . . . . . . . . . . . . . . . . . . .  11      4.3.  DOIC Overload Condition Reporting . . . . . . . . . . . .   9

      
     3.5.  Simplified Example Architecture . . . . . . . . . . . . .  12      4.4.  DOIC Extensibility  . . . . . . . . . . . . . . . . . . .  11

      
   4.  Solution Procedures . . . . . . . . . . . . . . . . . . . . .  13      4.5.  Simplified Example Architecture . . . . . . . . . . . . .  11

      
     4.1.  Capability Announcement . . . . . . . . . . . . . . . . .  13    5.  Solution Procedures . . . . . . . . . . . . . . . . . . . . .  12

      
       4.1.1.  Reacting Node Behavior  . . . . . . . . . . . . . . .  13      5.1.  Capability Announcement . . . . . . . . . . . . . . . . .  12

      
       4.1.2.  Reporting Node Behavior . . . . . . . . . . . . . . .  13        5.1.1.  Reacting Node Behavior  . . . . . . . . . . . . . . .  12

      
       4.1.3.  Agent Behavior  . . . . . . . . . . . . . . . . . . .  14        5.1.2.  Reporting Node Behavior . . . . . . . . . . . . . . .  13

      
     4.2.  Overload Report Processing  . . . . . . . . . . . . . . .  15        5.1.3.  Agent Behavior  . . . . . . . . . . . . . . . . . . .  14

      
       4.2.1.  Overload Control State  . . . . . . . . . . . . . . .  15      5.2.  Overload Report Processing  . . . . . . . . . . . . . . .  15

      
       4.2.2.  Reacting Node Behavior  . . . . . . . . . . . . . . .  19        5.2.1.  Overload Control State  . . . . . . . . . . . . . . .  15

      
       4.2.3.  Reporting Node Behavior . . . . . . . . . . . . . . .  20        5.2.2.  Reacting Node Behavior  . . . . . . . . . . . . . . .  19

      
     4.3.  Protocol Extensibility  . . . . . . . . . . . . . . . . .  22        5.2.3.  Reporting Node Behavior . . . . . . . . . . . . . . .  20

      
   5.  Loss Algorithm  . . . . . . . . . . . . . . . . . . . . . . .  22      5.3.  Protocol Extensibility  . . . . . . . . . . . . . . . . .  21

      
     5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  23    6.  Loss Algorithm  . . . . . . . . . . . . . . . . . . . . . . .  22

      
     5.2.  Reporting Node Behavior . . . . . . . . . . . . . . . . .  23      6.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  22

      
     5.3.  Reacting Node Behavior  . . . . . . . . . . . . . . . . .  24      6.2.  Reporting Node Behavior . . . . . . . . . . . . . . . . .  23

      
   6.  Attribute Value Pairs . . . . . . . . . . . . . . . . . . . .  25      6.3.  Reacting Node Behavior  . . . . . . . . . . . . . . . . .  23

      
     6.1.  OC-Supported-Features AVP . . . . . . . . . . . . . . . .  25    7.  Attribute Value Pairs . . . . . . . . . . . . . . . . . . . .  24

      
     6.2.  OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . .  25      7.1.  OC-Supported-Features AVP . . . . . . . . . . . . . . . .  24

      
     6.3.  OC-OLR AVP  . . . . . . . . . . . . . . . . . . . . . . .  26      7.2.  OC-Feature-Vector AVP . . . . . . . . . . . . . . . . . .  25

      
     6.4.  OC-Sequence-Number AVP  . . . . . . . . . . . . . . . . .  26      7.3.  OC-OLR AVP  . . . . . . . . . . . . . . . . . . . . . . .  25

      
     6.5.  OC-Validity-Duration AVP  . . . . . . . . . . . . . . . .  27      7.4.  OC-Sequence-Number AVP  . . . . . . . . . . . . . . . . .  26

      
     6.6.  OC-Report-Type AVP  . . . . . . . . . . . . . . . . . . .  27      7.5.  OC-Validity-Duration AVP  . . . . . . . . . . . . . . . .  26

      
     6.7.  OC-Reduction-Percentage AVP . . . . . . . . . . . . . . .  27      7.6.  OC-Report-Type AVP  . . . . . . . . . . . . . . . . . . .  26

      
     6.8.  Attribute Value Pair flag rules . . . . . . . . . . . . .  28      7.7.  OC-Reduction-Percentage AVP . . . . . . . . . . . . . . .  26

      
   7.  Error Response Codes  . . . . . . . . . . . . . . . . . . . .  28      7.8.  Attribute Value Pair flag rules . . . . . . . . . . . . .  27

      
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  29    8.  Error Response Codes  . . . . . . . . . . . . . . . . . . . .  27

      
     8.1.  AVP codes . . . . . . . . . . . . . . . . . . . . . . . .  29    9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28

      
     8.2.  New registries  . . . . . . . . . . . . . . . . . . . . .  29      9.1.  AVP codes . . . . . . . . . . . . . . . . . . . . . . . .  28

      
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  30      9.2.  New registries  . . . . . . . . . . . . . . . . . . . . .  28

      
     9.1.  Potential Threat Modes  . . . . . . . . . . . . . . . . .  30    10. Security Considerations . . . . . . . . . . . . . . . . . . .  29

      
     9.2.  Denial of Service Attacks . . . . . . . . . . . . . . . .  31      10.1.  Potential Threat Modes . . . . . . . . . . . . . . . . .  29

      
     9.3.  Non-Compliant Nodes . . . . . . . . . . . . . . . . . . .  32      10.2.  Denial of Service Attacks  . . . . . . . . . . . . . . .  30

      
     9.4.  End-to End-Security Issues  . . . . . . . . . . . . . . .  32      10.3.  Non-Compliant Nodes  . . . . . . . . . . . . . . . . . .  31

      
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  33      10.4.  End-to End-Security Issues . . . . . . . . . . . . . . .  31

      
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  34    11. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  32

      
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  34    12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  33

      
     11.2.  Informative References . . . . . . . . . . . . . . . . .  34      12.1.  Normative References . . . . . . . . . . . . . . . . . .  33

      
   Appendix A.  Issues left for future specifications  . . . . . . .  34      12.2.  Informative References . . . . . . . . . . . . . . . . .  33

      
     A.1.  Additional traffic abatement algorithms . . . . . . . . .  35    Appendix A.  Issues left for future specifications  . . . . . . .  33

      
     A.2.  Agent Overload  . . . . . . . . . . . . . . . . . . . . .  35      A.1.  Additional traffic abatement algorithms . . . . . . . . .  33

      
     A.3.  New Error Diagnostic AVP  . . . . . . . . . . . . . . . .  35      A.2.  Agent Overload  . . . . . . . . . . . . . . . . . . . . .  34

      
   Appendix B.  Deployment Considerations  . . . . . . . . . . . . .  35      A.3.  New Error Diagnostic AVP  . . . . . . . . . . . . . . . .  34

      
   Appendix C.  Requirements Conformance Analysis  . . . . . . . . .  35    Appendix B.  Deployment Considerations  . . . . . . . . . . . . .  34

      
     C.1.  Deferred Requirements . . . . . . . . . . . . . . . . . .  36    Appendix C.  Requirements Conformance Analysis  . . . . . . . . .  34

      
     C.2.  Detection of non-supporting Intermediaries  . . . . . . .  36      C.1.  Deferred Requirements . . . . . . . . . . . . . . . . . .  34

      
     C.3.  Implicit Application Indication . . . . . . . . . . . . .  36      C.2.  Detection of non-supporting Intermediaries  . . . . . . .  35

      
     C.4.  Stateless Operation . . . . . . . . . . . . . . . . . . .  37      C.3.  Implicit Application Indication . . . . . . . . . . . . .  35

      
     C.5.  No New Vulnerabilities  . . . . . . . . . . . . . . . . .  37      C.4.  Stateless Operation . . . . . . . . . . . . . . . . . . .  35

      
     C.6.  Detailed Requirements . . . . . . . . . . . . . . . . . .  37      C.5.  No New Vulnerabilities  . . . . . . . . . . . . . . . . .  36

      
       C.6.1.  General . . . . . . . . . . . . . . . . . . . . . . .  37      C.6.  Detailed Requirements . . . . . . . . . . . . . . . . . .  36

      
       C.6.2.  Performance . . . . . . . . . . . . . . . . . . . . .  39        C.6.1.  General . . . . . . . . . . . . . . . . . . . . . . .  36

      
       C.6.3.  Heterogeneous Support for Solution  . . . . . . . . .  41        C.6.2.  Performance . . . . . . . . . . . . . . . . . . . . .  37

      
       C.6.4.  Granular Control  . . . . . . . . . . . . . . . . . .  43        C.6.3.  Heterogeneous Support for Solution  . . . . . . . . .  40

      
       C.6.5.  Priority and Policy . . . . . . . . . . . . . . . . .  43        C.6.4.  Granular Control  . . . . . . . . . . . . . . . . . .  41

      
       C.6.6.  Security  . . . . . . . . . . . . . . . . . . . . . .  44        C.6.5.  Priority and Policy . . . . . . . . . . . . . . . . .  42

      
       C.6.7.  Flexibility and Extensibility . . . . . . . . . . . .  45        C.6.6.  Security  . . . . . . . . . . . . . . . . . . . . . .  43

      
        C.6.7.  Flexibility and Extensibility . . . . . . . . . . . .  44

      
   Appendix D.  Considerations for Applications Integrating the DOIC    Appendix D.  Considerations for Applications Integrating the DOIC

      

      
                Solution . . . . . . . . . . . . . . . . . . . . . .  46                 Solution . . . . . . . . . . . . . . . . . . . . . .  45

      
     D.1.  Application Classification  . . . . . . . . . . . . . . .  47      D.1.  Application Classification  . . . . . . . . . . . . . . .  45

      
     D.2.  Application Type Overload Implications  . . . . . . . . .  48      D.2.  Application Type Overload Implications  . . . . . . . . .  46

      
     D.3.  Request Transaction Classification  . . . . . . . . . . .  49      D.3.  Request Transaction Classification  . . . . . . . . . . .  47

      
     D.4.  Request Type Overload Implications  . . . . . . . . . . .  50      D.4.  Request Type Overload Implications  . . . . . . . . . . .  48

      
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  51    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  50

      
 

      
1.  Introduction 1.  Introduction

      
 

      
   This specification defines a base solution for Diameter overload    This specification defines a base solution for Diameter overload

      
   control, referred to as Diameter Overload Indication Conveyance    control, referred to as Diameter Overload Indication Conveyance

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

      
 

      
   This specification addresses Diameter overload control between    This specification addresses Diameter overload control between

      
   Diameter nodes that support the DOIC solution.  The solution, which    Diameter nodes that support the DOIC solution.  The solution, which

      
   is designed to apply to existing and future Diameter applications,    is designed to apply to existing and future Diameter applications,

      
   requires no changes to the Diameter base protocol [RFC6733] and is    requires no changes to the Diameter base protocol [RFC6733] and is

      
   deployable in environments where some Diameter nodes do not implement    deployable in environments where some Diameter nodes do not implement

      
   the Diameter overload control solution defined in this specification.    the Diameter overload control solution defined in this specification.

      
 

      

      
    A new application specification can incorporate the overload control

      
    mechanism specified in this document by making it mandatory to

      
    implement for the application and referencing this specification

      
    normatively.  It is the responsibility of the Diameter application

      
    designers to define how overload control mechanisms works on that

      
    application.

      
                                                                          

      
   Note that the 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    does not address all the requirements listed in [RFC7068].  A number

      
   of overload control related features are left for future    of overload control related features are left for future

      
   specifications.  See Appendix A for a list of extensions that are    specifications.  See Appendix A for a list of extensions that are

      
   currently being considered.  See Appendix C for an analysis of    currently being considered.  See Appendix C for an analysis of

      
   conformance to the requirements specified in [RFC7068].    conformance to the requirements specified in [RFC7068].

      
 

      
2.  Terminology and Abbreviations 2.  Terminology and Abbreviations

      
 

      
   Abatement    Abatement

      
 

      
      Reaction to receipt of an overload report resulting in a reduction       Reaction to receipt of an overload report resulting in a reduction

      
      in traffic sent to the reporting node.  Abatement actions include       in traffic sent to the reporting node.  Abatement actions include

      
      diversion and throttling.       diversion and throttling.

      
 

      
   Abatement Algorithm    Abatement Algorithm

      
 

      

      
      A mechanism requested by reporting nodes and used by reacting       An extensible mechanism requested by reporting nodes and used by

      
      nodes to reduce the amount of traffic sent during an occurrence of       reacting nodes to reduce the amount of traffic sent during an

      
      overload control.       occurrence of overload control.

      
 

      
   Diversion    Diversion

      
 

      

      
      A mechanism used for overload abatement by selecting a different       An overload abatement mechanism, where the reacting node selects

      
      path for requests.       alternate destinations or paths for for requests.

      
 

      
   Host-Routed Requests    Host-Routed Requests

      
 

      
      Requests that a reacting node knows will be served by a particular       Requests that a reacting node knows will be served by a particular

      
      host, either due to the presence of a Destination-Host AVP, or by       host, either due to the presence of a Destination-Host AVP, or by

      
      some other local knowledge on the part of the reacting node.       some other local knowledge on the part of the reacting node.

      
 

      
   Overload Control State (OCS)    Overload Control State (OCS)

      
 

      

      
      Reporting and reacting node internally maintained state describing       Internal state maintained by a reporting or reacting node

      
      occurrences of overload control.       describing occurrences of overload control.

      
 

      
   Overload Report (OLR)    Overload Report (OLR)

      
 

      
      Overload control information for a particular overload occurrence       Overload control information for a particular overload occurrence

      
      sent by a reporting node.       sent by a reporting node.

      
 

      
   Reacting Node    Reacting Node

      
 

      
      A Diameter node that acts upon an overload report.       A Diameter node that acts upon an overload report.

      
 

      
   Realm-Routed Requests    Realm-Routed Requests

      

      
      Requests that a reacting node does not know the host that will       Requests that a reacting node does not know which host will

      
      service the request.       service the request.

      
 

      
   Reporting Node    Reporting Node

      
 

      
      A Diameter node that generates an overload report.  (This may or       A Diameter node that generates an overload report.  (This may or

      
      may not be the overloaded node.)       may not be the overloaded node.)

      
 

      
   Throttling    Throttling

      
 

      
      A mechanism for overload abatement that limits the number of       A mechanism for overload abatement that limits the number of

      
      requests sent by the DIOC reacting node.  Throttling can include a       requests sent by the DIOC reacting node.  Throttling can include a

      

      
      Diameter Client not sending requests, or a Diameter Agent or       Diameter Client choosing to not send requests, or a Diameter Agent

      
      Server rejecting requests with appropriate error responses.  In       or Server rejecting requests with appropriate error responses.  In

      
      both cases the result of the throttling is a permanent rejection       both cases the result of the throttling is a permanent rejection

      
      of the transaction.       of the transaction.

      
 

      

      
3.  Solution Overview 3.  Conventions Used in This Document

      
 

      
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

      
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

      
    document are to be interpreted as described in RFC 2119 [RFC2119].

      
 

      
 4.  Solution Overview

      
 

      
   The Diameter Overload Information Conveyance (DOIC) solution allows    The Diameter Overload Information Conveyance (DOIC) solution allows

      
   Diameter nodes to request other Diameter nodes to perform overload    Diameter nodes to request other Diameter nodes to perform overload

      
   abatement actions, that is, actions to reduce the load offered to the    abatement actions, that is, actions to reduce the load offered to the

      
   overloaded node or realm.    overloaded node or realm.

      
 

      
   A Diameter node that supports DOIC is known as a "DOIC node".  Any    A Diameter node that supports DOIC is known as a "DOIC node".  Any

      
   Diameter node can act as a DOIC node, including Diameter Clients,    Diameter node can act as a DOIC node, including Diameter Clients,

      
   Diameter Servers, and Diameter Agents.  DOIC nodes are further    Diameter Servers, and Diameter Agents.  DOIC nodes are further

      
   divided into "Reporting Nodes" and "Reacting Nodes."  A reporting    divided into "Reporting Nodes" and "Reacting Nodes."  A reporting

      
 

      
skipping to change at page 6, line 10 skipping to change at page 6, line 16

      
 

      
   Likewise, a Diameter Agent may act as a reacting node from the    Likewise, a Diameter Agent may act as a reacting node from the

      
   perspective of upstream nodes, and a reporting node from the    perspective of upstream nodes, and a reporting node from the

      
   perspective of downstream nodes.    perspective of downstream nodes.

      
 

      
   DOIC nodes do not generate new messages to carry DOIC related    DOIC nodes do not generate new messages to carry DOIC related

      
   information.  Rather, they "piggyback" DOIC information over existing    information.  Rather, they "piggyback" DOIC information over existing

      
   Diameter messages by inserting new AVPs into existing Diameter    Diameter messages by inserting new AVPs into existing Diameter

      
   requests and responses.  Nodes indicate support for DOIC, and any    requests and responses.  Nodes indicate support for DOIC, and any

      
   needed DOIC parameters, by inserting an OC-Supported-Features AVP    needed DOIC parameters, by inserting an OC-Supported-Features AVP

      

      
   (Section 6.2) into existing requests and responses.  Reporting nodes    (Section 7.2) into existing requests and responses.  Reporting nodes

      
   send OLRs by inserting OC-OLR AVPs (Section 6.3).    send OLRs by inserting OC-OLR AVPs (Section 7.3).

      
 

      
   A given OLR applies to the Diameter realm and application of the    A given OLR applies to the Diameter realm and application of the

      
   Diameter message that carries it.  If a reporting node supports more    Diameter message that carries it.  If a reporting node supports more

      
   than one realm and/or application, it reports independently for each    than one realm and/or application, it reports independently for each

      
   combination of realm and application.  Similarly, the OC-Supported-    combination of realm and application.  Similarly, the OC-Supported-

      
   Features AVP applies to the realm and application of the enclosing    Features AVP applies to the realm and application of the enclosing

      
   message.  This implies that a node may support DOIC for one    message.  This implies that a node may support DOIC for one

      
   application and/or realm, but not another, and may indicate different    application and/or realm, but not another, and may indicate different

      
   DOIC parameters for each application and realm for which it supports    DOIC parameters for each application and realm for which it supports

      
   DOIC.    DOIC.

      
 

      
   Reacting nodes perform overload abatement according to an agreed-upon    Reacting nodes perform overload abatement according to an agreed-upon

      
   abatement algorithm.  An abatement algorithm defines the meaning of    abatement algorithm.  An abatement algorithm defines the meaning of

      
   some of the parameters of an OLR and the procedures required for    some of the parameters of an OLR and the procedures required for

      
   overload abatement.  An overload abatement algorithm separates    overload abatement.  An overload abatement algorithm separates

      
   Diameter requests into two sets.  The first set contains the requests    Diameter requests into two sets.  The first set contains the requests

      
   that are to undergo overload abatement treatment of either throttling    that are to undergo overload abatement treatment of either throttling

      
   or diversion.  The second set contains the requests that are to be    or diversion.  The second set contains the requests that are to be

      
   given normal routing treatment.  This document specifies a single    given normal routing treatment.  This document specifies a single

      

      
   must-support algorithm, namely the "loss" algorithm (Section 5).    must-support algorithm, namely the "loss" algorithm (Section 6).

      
   Future specifications may introduce new algorithms.    Future specifications may introduce new algorithms.

      
 

      
   Overload conditions may vary in scope.  For example, a single    Overload conditions may vary in scope.  For example, a single

      
   Diameter node may be overloaded, in which case reacting nodes may    Diameter node may be overloaded, in which case reacting nodes may

      
   attempt to send requests to other destinations.  On the other hand,    attempt to send requests to other destinations.  On the other hand,

      
   an entire Diameter realm may be overloaded, in which case such    an entire Diameter realm may be overloaded, in which case such

      
   attempts would do harm.  DOIC OLRs have a concept of "report type"    attempts would do harm.  DOIC OLRs have a concept of "report type"

      

      
   (Section 6.6), where the type defines such behaviors.  Report types    (Section 7.6), where the type defines such behaviors.  Report types

      
   are extensible.  This document defines report types for overload of a    are extensible.  This document defines report types for overload of a

      
   specific host, and for overload of an entire realm.    specific host, and for overload of an entire realm.

      
 

      

      
   A report of type "HOST_REPORT" is sent to indicate the overload of a    DOIC works through non supporting Diameter Agents that properly pass

      
   specific host, identified by the Origin-Host AVP of the message    unknown AVPs unchanged.

      
   containing the OLR, for the application-id indicated in the 

      
   transaction.  When receiving an OLR of type "HOST_REPORT", a reacting 

      
   node applies overload abatement treatment to the host-routed requests 

      
   identified by the overload abatement algorithm (see definition in 

      
   Section 2) sent for this application to the overloaded host. 

      
 

      
   A report of type "REALM_REPORT" is sent to indicate the overload of a 

      
   realm for the application-id indicated in the transaction.  The 

      
   overloaded realm is identified by the Destination-Realm AVP of the 

      
   message containing the OLR.  When receiving an OLR of type 

      
   "REALM_REPORT", a reacting node applies overload abatement treatment 

      
   to realm-routed requests identified by the overload abatement 

      
   algorithm (see definition in Section 2) sent for this application to 

      
   the overloaded realm. 

      
 

      
   While a reporting node sends OLRs to "adjacent" reacting nodes, nodes 

      
   that are "adjacent" for DOIC purposes may not be adjacent from a 

      
   Diameter, or transport, perspective.  For example, one or more 

      
   Diameter agents that do not support DOIC may exist between a given 

      
   pair of reporting and reacting nodes, as long as those agents pass 

      
   unknown AVPs through unchanged.  The report types described in this 

      
   document can safely pass through non-supporting agents.  This may not 

      
   be true for report types defined in future specifications. 

      
 

      

      
3.1.  Piggybacking 4.1.  Piggybacking

      
 

      
   There is no new Diameter application defined to carry overload    There is no new Diameter application defined to carry overload

      
   related AVPs.  The overload control AVPs defined in this    related AVPs.  The overload control AVPs defined in this

      
   specification have been designed to be piggybacked on top of existing    specification have been designed to be piggybacked on top of existing

      

      
   application messages.  This is made possible by adding overload    application messages.  This is made possible by adding the optional

      
   control AVPs, the OC-OLR AVP and the OC-Supported-Features AVP, as    overload control AVPs OC-OLR and OC-Supported-Features into existing

      
   optional AVPs into existing commands when the corresponding Command    commands.

      
   Code Format (CCF) specification allows adding new optional AVPs (see 

      
   Section 1.3.4 of [RFC6733]). 

      
 

      
   Reacting nodes indicate support for DOIC by including the OC-    Reacting nodes indicate support for DOIC by including the OC-

      
   Supported-Features AVP in all request messages originated or relayed    Supported-Features AVP in all request messages originated or relayed

      
   by the reacting node.    by the reacting node.

      
 

      
   Reporting nodes indicate support for DOIC by including the OC-    Reporting nodes indicate support for DOIC by including the OC-

      
   Supported-Features AVP in all answer messages originated or relayed    Supported-Features AVP in all answer messages originated or relayed

      
   by the reporting node that are in response to a request that    by the reporting node that are in response to a request that

      

      
   contained the OC-Supported-Features AVP.  Reporting nodes also    contained the OC-Supported-Features AVP.  Reporting nodes may include

      
   include overload reports using the OC-OLR AVP in answer messages.    overload reports using the OC-OLR AVP in answer messages.

      
 

      
   Note that the overload control solution does not have fixed server    Note that the overload control solution does not have fixed server

      
   and client roles.  The DOIC node role is determined based on the    and client roles.  The DOIC node role is determined based on the

      
   message type: whether the message is a request (i.e. sent by a    message type: whether the message is a request (i.e. sent by a

      

      
   "reacting node") or an answer (i.e. send by a "reporting node").    "reacting node") or an answer (i.e. sent by a "reporting node").

      
   Therefore, in a typical "client-server" deployment, the Diameter    Therefore, in a typical "client-server" deployment, the Diameter

      

      
   Client MAY report its overload condition to the Diameter Server for    Client may report its overload condition to the Diameter Server for

      
   any Diameter Server initiated message exchange.  An example of such    any Diameter Server initiated message exchange.  An example of such

      
   is the Diameter Server requesting a re-authentication from a Diameter    is the Diameter Server requesting a re-authentication from a Diameter

      
   Client.    Client.

      
 

      

      
3.2.  DOIC Capability Announcement 4.2.  DOIC Capability Announcement

      
 

      
   The DOIC solution supports the ability for Diameter nodes to    The DOIC solution supports the ability for Diameter nodes to

      
   determine if other nodes in the path of a request support the    determine if other nodes in the path of a request support the

      
   solution.  This capability is referred to as DOIC Capability    solution.  This capability is referred to as DOIC Capability

      
   Announcement (DCA) and is separate from Diameter Capability Exchange.    Announcement (DCA) and is separate from Diameter Capability Exchange.

      
 

      
   The DCA mechanism uses the OC-Supported-Features AVPs to indicate the    The DCA mechanism uses the OC-Supported-Features AVPs to indicate the

      
   Diameter overload features supported.    Diameter overload features supported.

      
 

      
   The first node in the path of a Diameter request that supports the    The first node in the path of a Diameter request that supports the

      
   DOIC solution inserts the OC-Supported-Features AVP in the request    DOIC solution inserts the OC-Supported-Features AVP in the request

      
   message.    message.

      
 

      

      
    The individual features supported by the DOIC nodes are indicated in

      
    the OC-Feature-Vector AVP.  Any semantics associated with the

      
    features will be defined in extension specifications that introduce

      
    the features.

      
                                                                          

      
      Note: As discussed elsewhere in the document, agents in the path       Note: As discussed elsewhere in the document, agents in the path

      
      of the request can modify the OC-Supported-Features AVP.       of the request can modify the OC-Supported-Features AVP.

      
 

      
      Note: The DOIC solution must support deployments where Diameter       Note: The DOIC solution must support deployments where Diameter

      
      Clients and/or Diameter Servers do not support the DOIC solution.       Clients and/or Diameter Servers do not support the DOIC solution.

      
      In this scenario, Diameter Agents that support the DOIC solution       In this scenario, Diameter Agents that support the DOIC solution

      
      may handle overload abatement for the non supporting Diameter       may handle overload abatement for the non supporting Diameter

      
      nodes.  In this case the DOIC agent will insert the OC-Supported-       nodes.  In this case the DOIC agent will insert the OC-Supported-

      
      Features AVP in requests that do not already contain one, telling       Features AVP in requests that do not already contain one, telling

      
      the reporting node that there is a DOIC node that will handle       the reporting node that there is a DOIC node that will handle

      
      overload abatement.  For transactions where there was an OC-       overload abatement.  For transactions where there was an OC-

      
      Supporting-Features AVP in the request, the agent will insert the       Supporting-Features AVP in the request, the agent will insert the

      
      OC-Supported-Features AVP in answers, telling the reacting node       OC-Supported-Features AVP in answers, telling the reacting node

      
      that there is a reporting node.       that there is a reporting node.

      
 

      

      
   The OC-Feature-Vector AVP will contain an indication of support for    The OC-Feature-Vector AVP will always contain an indication of

      
   the loss overload abatement algorithm defined in this specification    support for the loss overload abatement algorithm defined in this

      
   (see Section 5).  This ensures that a reporting node always supports    specification (see Section 6).  This ensures that a reporting node

      
   at least one of the advertized abatement algorithms received in a    always supports at least one of the advertized abatement algorithms

      
   request messages.    received in a request messages.

      
 

      
   The reporting node inserts the OC-Supported-Features AVP in all    The reporting node inserts the OC-Supported-Features AVP in all

      
   answer messages to requests that contained the OC-Supported-Features    answer messages to requests that contained the OC-Supported-Features

      
   AVP.  The contents of the reporting node's OC-Supported-Features AVP    AVP.  The contents of the reporting node's OC-Supported-Features AVP

      
   indicate the set of Diameter overload features supported by the    indicate the set of Diameter overload features supported by the

      
   reporting node.  This specification defines one exception - the    reporting node.  This specification defines one exception - the

      
   reporting node only includes an indication of support for one    reporting node only includes an indication of support for one

      
   overload abatement algorithm, independent of the number of overload    overload abatement algorithm, independent of the number of overload

      
   abatement algorithms actually supported by the reacting node.  The    abatement algorithms actually supported by the reacting node.  The

      
   overload abatement algorithm indicated is the algorithm that the    overload abatement algorithm indicated is the algorithm that the

      
 

      
skipping to change at page 9, line 15 skipping to change at page 8, line 49

      
   requested.    requested.

      
 

      
      Note that the loss algorithm defined in this document is a       Note that the loss algorithm defined in this document is a

      
      stateless abatement algorithm.  As a result it does not require       stateless abatement algorithm.  As a result it does not require

      
      any actions by reacting nodes prior to the receipt of an overload       any actions by reacting nodes prior to the receipt of an overload

      
      report.  Stateful abatement algorithms that base the abatement       report.  Stateful abatement algorithms that base the abatement

      
      logic on a history of request messages sent might require reacting       logic on a history of request messages sent might require reacting

      
      nodes to maintain state in advance of receiving an overload report       nodes to maintain state in advance of receiving an overload report

      
      to ensure that the overload reports can be properly handled.       to ensure that the overload reports can be properly handled.

      
 

      

      
   Reporting nodes are allowed to change the overload abatement    Reporting nodes can change the overload abatement algorithm indicated

      
   algorithm indicated in the OC-Feature-Vector AVP if the reporting    in the OC-Feature-Vector AVP if the reporting node is not currently

      
   node is not currently in an overload condition and sending overload    in an overload condition and sending overload reports.  The reporting

      
   reports.  The reporting node is not allowed to change the overload    node is not allowed to change the overload abatement algorithm while

      
   abatement algorithm while the reporting node is in an overload    the reporting node is in an overload condition.

      
   condition. 

      
                                                                          

      
   The individual features supported by the DOIC nodes are indicated in 

      
   the OC-Feature-Vector AVP.  Any semantics associated with the 

      
   features will be defined in extension specifications that introduce 

      
   the features. 

      
 

      
   The DCA mechanism must also allow the scenario where the set of    The DCA mechanism must also allow the scenario where the set of

      
   features supported by the sender of a request and by agents in the    features supported by the sender of a request and by agents in the

      
   path of a request differ.  In this case, the agent can update the OC-    path of a request differ.  In this case, the agent can update the OC-

      
   Supported-Features AVP to reflect the mixture of the two sets of    Supported-Features AVP to reflect the mixture of the two sets of

      
   supported features.    supported features.

      
 

      
      Note: The logic to determine if the content of the OC-Supported-       Note: The logic to determine if the content of the OC-Supported-

      
      Features AVP should be changed is out-of-scope for this document,       Features AVP should be changed is out-of-scope for this document,

      
      as is the logic to determine the content of a modified OC-       as is the logic to determine the content of a modified OC-

      
      Supported-Features AVP.  These are left to implementation       Supported-Features AVP.  These are left to implementation

      
      decisions.  Care must be taken not to introduce interoperability       decisions.  Care must be taken not to introduce interoperability

      
      issues for downstream or upstream DOIC nodes.       issues for downstream or upstream DOIC nodes.

      
 

      

      
3.3.  DOIC Overload Condition Reporting 4.3.  DOIC Overload Condition Reporting

      
 

      
   As with DOIC capability announcement, overload condition reporting    As with DOIC capability announcement, overload condition reporting

      

      
   uses new AVPs (Section 6.3) to indicate an overload condition.    uses new AVPs (Section 7.3) to indicate an overload condition.

      
 

      
   The OC-OLR AVP is referred to as an overload report.  The OC-OLR AVP    The OC-OLR AVP is referred to as an overload report.  The OC-OLR AVP

      
   includes the type of report, a sequence number, the length of time    includes the type of report, a sequence number, the length of time

      
   that the report is valid and abatement algorithm specific AVPs.    that the report is valid and abatement algorithm specific AVPs.

      
 

      

      
   Two types of overload reports are defined in this document, host    Two types of overload reports are defined in this document: host

      
   reports and realm reports.    reports and realm reports.

      
 

      
   A report of type "HOST_REPORT" is sent to indicate the overload of a    A report of type "HOST_REPORT" is sent to indicate the overload of a

      
   specific Diameter node for the application-id indicated in the    specific Diameter node for the application-id indicated in the

      
   transaction.  When receiving an OLR of type host, a reacting node    transaction.  When receiving an OLR of type host, a reacting node

      
   applies overload abatement to what is referred to in this document as    applies overload abatement to what is referred to in this document as

      
   host-routed requests.  The reacting node applies overload abatement    host-routed requests.  The reacting node applies overload abatement

      
   on those host-routed requests which the reacting node knows will be    on those host-routed requests which the reacting node knows will be

      
   served by the server that matches the Origin-Host AVP of the received    served by the server that matches the Origin-Host AVP of the received

      
   message that contained the received OLR of type host.    message that contained the received OLR of type host.

      
 

      
skipping to change at page 10, line 40 skipping to change at page 10, line 19

      
      which apply to the same Diameter entity exist.  Reacting nodes       which apply to the same Diameter entity exist.  Reacting nodes

      
      have no way of determining the source and, as such, will treat       have no way of determining the source and, as such, will treat

      
      them as coming from a single source.  Variance in sequence numbers       them as coming from a single source.  Variance in sequence numbers

      
      between the two sources can then cause incorrect overload       between the two sources can then cause incorrect overload

      
      abatement treatment to be applied for indeterminate periods of       abatement treatment to be applied for indeterminate periods of

      
      time.       time.

      
 

      
   Reporting nodes are responsible for determining the need for a    Reporting nodes are responsible for determining the need for a

      
   reduction of traffic.  The method for making this determination is    reduction of traffic.  The method for making this determination is

      
   implementation specific and depend on the type of overload report    implementation specific and depend on the type of overload report

      

      
   being generated.  A host-report, for instance, will generally be    being generated.  A host-report might be generated by tracking use of

      
   generated by tracking utilization of resources required by the host    resources required by the host to handle transactions for the

      
   to handle transactions for the Diameter application.  A realm-report    Diameter application.  A realm-report generally impacts the traffic

      
   generally impacts the traffic sent to multiple hosts and, as such,    sent to multiple hosts and, as such, requires tracking the capacity

      
   requires tracking the capacity of all servers able to handle realm-    of all servers able to handle realm- routed requests for the

      
   routed requests for the application and realm.    application and realm.

      
 

      
   Once a reporting node determines the need for a reduction in traffic,    Once a reporting node determines the need for a reduction in traffic,

      
   it uses the DOIC defined AVPs to report on the condition.  These AVPs    it uses the DOIC defined AVPs to report on the condition.  These AVPs

      
   are included in answer messages sent or relayed by the reporting    are included in answer messages sent or relayed by the reporting

      
   node.  The reporting node indicates the overload abatement algorithm    node.  The reporting node indicates the overload abatement algorithm

      
   that is to be used to handle the traffic reduction in the OC-    that is to be used to handle the traffic reduction in the OC-

      
   Supported-Features AVP.  The OC-OLR AVP is used to communicate    Supported-Features AVP.  The OC-OLR AVP is used to communicate

      
   information about the requested reduction.    information about the requested reduction.

      
 

      

      
   Reacting nodes, upon receipt of an overload report, are responsible    Reacting nodes, upon receipt of an overload report, applying the

      
   for applying the overload abatement algorithm to traffic impacted by    overload abatement algorithm to traffic impacted by the overload

      
   the overload report.  The method used to determine the requests that    report.  The method used to determine the requests that are to

      
   are to receive overload abatement treatment is dependent on the    receive overload abatement treatment is dependent on the abatement

      
   abatement algorithm.  The loss abatement algorithm is defined in this    algorithm.  The loss abatement algorithm is defined in this document

      
   document (Section 5).  Other abatement algorithms can be defined in    (Section 6).  Other abatement algorithms can be defined in extensions

      
   extensions to the DOIC solutions.    to the DOIC solutions.

      
 

      
   Two types of overload abatement treatment are defined, diversion and    Two types of overload abatement treatment are defined, diversion and

      
   throttling.  Reacting nodes are responsible for determining which    throttling.  Reacting nodes are responsible for determining which

      
   treatment is appropriate for individual requests.    treatment is appropriate for individual requests.

      
 

      
   As the conditions that lead to the generation of the overload report    As the conditions that lead to the generation of the overload report

      
   change the reporting node can send new overload reports requesting    change the reporting node can send new overload reports requesting

      
   greater reduction if the condition gets worse or less reduction if    greater reduction if the condition gets worse or less reduction if

      
   the condition improves.  The reporting node sends an overload report    the condition improves.  The reporting node sends an overload report

      
   with a duration of zero to indicate that the overload condition has    with a duration of zero to indicate that the overload condition has

      
   ended and abatement is no longer needed.    ended and abatement is no longer needed.

      
 

      
   The reacting node also determines when the overload report expires    The reacting node also determines when the overload report expires

      
   based on the OC-Validity-Duration AVP in the overload report and    based on the OC-Validity-Duration AVP in the overload report and

      
   stops applying the abatement algorithm when the report expires.    stops applying the abatement algorithm when the report expires.

      
 

      

      
3.4.  DOIC Extensibility 4.4.  DOIC Extensibility

      
 

      
   The DOIC solution is designed to be extensible.  This extensibility    The DOIC solution is designed to be extensible.  This extensibility

      
   is based on existing Diameter based extensibility mechanisms, along    is based on existing Diameter based extensibility mechanisms, along

      
   with the DOIC capability announcement mechanism.    with the DOIC capability announcement mechanism.

      
 

      
   There are multiple categories of extensions that are expected.  This    There are multiple categories of extensions that are expected.  This

      
   includes the definition of new overload abatement algorithms, the    includes the definition of new overload abatement algorithms, the

      
   definition of new report types and the definition of new scopes of    definition of new report types and the definition of new scopes of

      
   messages impacted by an overload report.    messages impacted by an overload report.

      
 

      

      
   The DOIC solution uses the OC-Supported-Features AVP for DOIC nodes    A DOIC node communicates supported features by including them in the

      
   to communicate supported features.  The specific features supported    OC-Feature-Vector AVP, as a sub-AVP of OC-Supported-Features.  Any

      
   by the DOIC node are indicated in the OC-Feature-Vector AVP.  DOIC    non-backwards compatible DOIC extensions define new values for the

      
   extensions that require new normative behavior define new values for    OC-Feature-Vector AVP.  DOIC extensions also have the ability to add

      
   the OC-Feature-Vector AVP.  DOIC extensions also have the ability to    new AVPs to the OC-Supported-Features AVP, if additional information

      
   add new AVPs to the OC-Supported-Features AVP, if additional    about the new feature is required.

      
   information about the new feature is required. 

      
 

      

      
   Reporting nodes use the OC-OLR AVP to communicate overload    Overload reports can be also extended by adding new sub-AVPs to the

      
   occurrences.  This AVP can also be extended to add new AVPs allowing    OC-OLR AVP, allowing reporting nodes to communicate additional

      
   reporting nodes to communicate additional information about handling    information about handling an overload condition.

      
   an overload condition. 

      
 

      
   If necessary, new extensions can also define new AVPs that are not    If necessary, new extensions can also define new AVPs that are not

      
   part of the OC-Supported-Features and OC-OLR group AVPs.  It is,    part of the OC-Supported-Features and OC-OLR group AVPs.  It is,

      
   however, recommended that DOIC extensions use the OC-Supported-    however, recommended that DOIC extensions use the OC-Supported-

      
   Features AVP and OC-OLR AVP to carry all DOIC related AVPs.    Features AVP and OC-OLR AVP to carry all DOIC related AVPs.

      
 

      

      
3.5.  Simplified Example Architecture 4.5.  Simplified Example Architecture

      
 

      
   Figure 1 illustrates the simplified architecture for Diameter    Figure 1 illustrates the simplified architecture for Diameter

      
   overload information conveyance.    overload information conveyance.

      
 

      
    Realm X                                  Same or other Realms     Realm X                                  Same or other Realms

      
   <--------------------------------------> <---------------------->    <--------------------------------------> <---------------------->

      
 

      
      +--^-----+                 : (optional) :       +--^-----+                 : (optional) :

      
      |Diameter|                 :            :       |Diameter|                 :            :

      
      |Server A|--+     .--.     : +---^----+ :     .--.       |Server A|--+     .--.     : +---^----+ :     .--.

      
 

      
skipping to change at page 13, line 5 skipping to change at page 12, line 34

      
                 Diameter Application Y   Diameter Application Y                  Diameter Application Y   Diameter Application Y

      
 

      
     Figure 1: Simplified architecture choices for overload indication      Figure 1: Simplified architecture choices for overload indication

      
                                 delivery                                  delivery

      
 

      
   In Figure 1, the Diameter overload indication can be conveyed (1)    In Figure 1, the Diameter overload indication can be conveyed (1)

      
   end-to-end between servers and clients or (2) between servers and    end-to-end between servers and clients or (2) between servers and

      
   Diameter agent inside the realm and then between the Diameter agent    Diameter agent inside the realm and then between the Diameter agent

      
   and the clients.    and the clients.

      
 

      

      
4.  Solution Procedures 5.  Solution Procedures

      
 

      
   This section outlines the normative behavior for the DOIC solution.    This section outlines the normative behavior for the DOIC solution.

      
 

      

      
4.1.  Capability Announcement 5.1.  Capability Announcement

      
 

      
   This section defines DOIC Capability Announcement (DCA) behavior.    This section defines DOIC Capability Announcement (DCA) behavior.

      
 

      

      
4.1.1.  Reacting Node Behavior 5.1.1.  Reacting Node Behavior

      
 

      
   A reacting node MUST include the OC-Supported-Features AVP in all    A reacting node MUST include the OC-Supported-Features AVP in all

      

      
   requests.  It MAY include the OC-Feature-Vector AVP.  If it does so,    requests.  It MAY include the OC-Feature-Vector AVP, as a sub-avp of

      
   it MUST indicate support for the "loss" algorithm.  If the reacting    OC-Supported-Features.  If it does so, it MUST indicate support for

      
   node is configured to support features (including other algorithms)    the "loss" algorithm.  If the reacting node is configured to support

      
   in addition to the loss algorithm, it MUST indicate such support in    features (including other algorithms) in addition to the loss

      
   an OC-Feature-Vector AVP.    algorithm, it MUST indicate such support in an OC-Feature-Vector AVP.

      
 

      
   An OC-Supported-Features AVP in answer messages indicates there is a    An OC-Supported-Features AVP in answer messages indicates there is a

      
   reporting node for the transaction.  The reacting node MAY take    reporting node for the transaction.  The reacting node MAY take

      
   action, for example creating state for some stateful abatement    action, for example creating state for some stateful abatement

      
   algorithm, based on the features indicated in the OC-Feature-Vector    algorithm, based on the features indicated in the OC-Feature-Vector

      
   AVP.    AVP.

      
 

      
      Note: The loss abatement algorithm does not require stateful       Note: The loss abatement algorithm does not require stateful

      

      
      behavior when there is no active overload report.  This behavior       behavior when there is no active overload report.

      
      is described in Section 4.2 and Section 5. 

      
 

      

      
4.1.2.  Reporting Node Behavior 5.1.2.  Reporting Node Behavior

      
 

      
   Upon receipt of a request message, a reporting node determines if    Upon receipt of a request message, a reporting node determines if

      
   there is a reacting node for the transaction based on the presence of    there is a reacting node for the transaction based on the presence of

      
   the OC-Supported-Features AVP in the request message.    the OC-Supported-Features AVP in the request message.

      
 

      
   If the request message contains an OC-Supported-Features AVP then a    If the request message contains an OC-Supported-Features AVP then a

      
   reporting node MUST include the OC-Supported-Features AVP in the    reporting node MUST include the OC-Supported-Features AVP in the

      
   answer message for that transaction.    answer message for that transaction.

      
 

      
   A reporting node MUST NOT include the OC-Supported-Features AVP, OC-    A reporting node MUST NOT include the OC-Supported-Features AVP, OC-

      
 

      
skipping to change at page 14, line 37 skipping to change at page 14, line 22

      
 

      
   The reporting node SHOULD indicate support for other DOIC features    The reporting node SHOULD indicate support for other DOIC features

      
   defined in extension drafts that it supports and that apply to the    defined in extension drafts that it supports and that apply to the

      
   transaction.    transaction.

      
 

      
      Note: Not all DOIC features will apply to all Diameter       Note: Not all DOIC features will apply to all Diameter

      
      applications or deployment scenarios.  The features included in       applications or deployment scenarios.  The features included in

      
      the OC-Feature-Vector AVP are based on local reporting node       the OC-Feature-Vector AVP are based on local reporting node

      
      policy.       policy.

      
 

      

      
4.1.3.  Agent Behavior 5.1.3.  Agent Behavior

      
 

      

      
   Diameter Agents that support DOIC SHOULD ensure that all messages    Diameter Agents that support DOIC MAY ensure that all messages

      
   relayed by the agent contain the OC-Supported-Features AVP.    relayed by the agent contain the OC-Supported-Features AVP.

      
 

      
   A Diameter Agent SHOULD take on reacting node behavior for Diameter    A Diameter Agent SHOULD take on reacting node behavior for Diameter

      
   endpoints that do not support the DOIC solution.  A Diameter Agent    endpoints that do not support the DOIC solution.  A Diameter Agent

      
   detects that a Diameter endpoint does not support DOIC reacting node    detects that a Diameter endpoint does not support DOIC reacting node

      
   behavior when there is no OC-Supported-Features AVP in a request    behavior when there is no OC-Supported-Features AVP in a request

      
   message.    message.

      
 

      
   For a Diameter Agent to be a reacting node for a non supporting    For a Diameter Agent to be a reacting node for a non supporting

      
   Diameter endpoint, the Diameter Agent MUST include the OC-Supported-    Diameter endpoint, the Diameter Agent MUST include the OC-Supported-

      

      
   Features AVP in request messages it receives that do not contain the    Features AVP in request messages it relays that do not contain the

      
   OC-Supported-Features AVP.    OC-Supported-Features AVP.

      
 

      

      
   A Diameter Agent SHOULD take on reporting node behavior for Diameter    A Diameter Agent MAY take on reporting node behavior for Diameter

      
   endpoints that do not support the DOIC solution.  A Diameter Agent    endpoints that do not support the DOIC solution.  The Diameter Agent

      
   detects that a Diameter endpoint does not support DOIC reporting node    MUST have visibility to all traffic destined for the non supporting

      
   behavior when there is no OC-Supported-Features AVP in an answer    host in order to become the reporting node for the Diameter endpoint.

      
   message for a transaction that contained the OC-Supported-Features    A Diameter Agent detects that a Diameter endpoint does not support

      
   AVP in the request message.    DOIC reporting node behavior when there is no OC-Supported-Features

      
    AVP in an answer message for a transaction that contained the OC-

      
   For a Diameter Agent to take on reporting node behavior for a non    Supported-Features AVP in the request message.

      
   supporting Diameter endpoint the Diameter Agent MUST include the OC- 

      
   Supported-Features AVP in answer messages it receives that do not 

      
   contain the OC-Supported-Features AVP. 

      
 

      
   As with a Diameter endpoint taking on reporting node behavior, a 

      
   Diameter Agent MUST NOT include the OC-Supported-Features AVP in 

      
   answer messages for transactions where the request message received 

      
   by the Diameter Agent had no OC-Supported-Features AVP. 

      
 

      

      
   If a request message already has the OC-Supported-Features AVP then a    If a request already has the OC-Supported-Features AVP, a Diameter

      
   Diameter Agent MAY leave it unchanged in the relayed message or MAY    agent MAY modify it to reflect the features appropriate for the

      
   modify it to reflect the features appropriate for the transaction.    transaction.  Otherwise, the agent relays the OC-Supported-Features

      
    AVP without change.

      
 

      
      For instance, if the agent supports a superset of the features       For instance, if the agent supports a superset of the features

      
      reported by the reacting node then the agent might choose, based       reported by the reacting node then the agent might choose, based

      
      on local policy, to advertise that superset of features to the       on local policy, to advertise that superset of features to the

      
      reporting node.       reporting node.

      
 

      
   If the Diameter Agent changes the OC-Supported-Features AVP in a    If the Diameter Agent changes the OC-Supported-Features AVP in a

      
   request message then it is likely it will also need to modify the OC-    request message then it is likely it will also need to modify the OC-

      

      
   Supported-Features AVP in the answer message for the transaction.  As    Supported-Features AVP in the answer message for the transaction.  A

      
   such, a Diameter Agent MAY modify the OC-Supported-Features AVP    Diameter Agent MAY modify the OC-Supported-Features AVP carried in

      
   carried in answer messages.    answer messages.

      
 

      
   When making changes to the OC-Supported-Features AVP the Diameter    When making changes to the OC-Supported-Features AVP the Diameter

      

      
   Agent needs to ensure that there is no ambiguity in DOIC behavior for    Agent needs to ensure that it does not introduce incorrect behavior

      
   both upstream and downstream DOIC nodes.    for either the upstream or downstream DOIC nodes..

      
 

      

      
4.2.  Overload Report Processing 5.2.  Overload Report Processing

      
 

      

      
4.2.1.  Overload Control State 5.2.1.  Overload Control State

      
 

      
   Both reacting and reporting nodes maintain Overload Control State    Both reacting and reporting nodes maintain Overload Control State

      
   (OCS) for active overload conditions.  The following sections define    (OCS) for active overload conditions.  The following sections define

      
   behavior associated with that OCS.    behavior associated with that OCS.

      
 

      

      
4.2.1.1.  Overload Control State for Reacting Nodes 5.2.1.1.  Overload Control State for Reacting Nodes

      
 

      
   A reacting node SHOULD maintain the following OCS per supported    A reacting node SHOULD maintain the following OCS per supported

      
   Diameter application:    Diameter application:

      
 

      
   o  A host-type OCS entry for each Destination-Host to which it sends    o  A host-type OCS entry for each Destination-Host to which it sends

      
      host-type requests and       host-type requests and

      
 

      
   o  A realm-type OCS entry for each Destination-Realm to which it    o  A realm-type OCS entry for each Destination-Realm to which it

      
      sends realm-type requests.       sends realm-type requests.

      
 

      
 

      
skipping to change at page 16, line 39 skipping to change at page 16, line 15

      
      the OC-OLR AVP and time of reception of the message carrying OC-       the OC-OLR AVP and time of reception of the message carrying OC-

      
      OLR AVP)       OLR AVP)

      
 

      
   o  Selected Abatement Algorithm (as received in the OC-Supported-    o  Selected Abatement Algorithm (as received in the OC-Supported-

      
      Features AVP)       Features AVP)

      
 

      
   o  Abatement Algorithm specific input data (as received in the OC-OLR    o  Abatement Algorithm specific input data (as received in the OC-OLR

      
      AVP, for example, OC-Reduction-Percentage for the Loss abatement       AVP, for example, OC-Reduction-Percentage for the Loss abatement

      
      algorithm)       algorithm)

      
 

      

      
4.2.1.2.  Overload Control State for Reporting Nodes 5.2.1.2.  Overload Control State for Reporting Nodes

      
 

      
   A reporting node SHOULD maintain OCS entries per supported Diameter    A reporting node SHOULD maintain OCS entries per supported Diameter

      
   application, per supported (and eventually selected) Abatement    application, per supported (and eventually selected) Abatement

      
   Algorithm and per report-type.    Algorithm and per report-type.

      
 

      
   An OCS entry is identified by the tuple of Application-Id, Report-    An OCS entry is identified by the tuple of Application-Id, Report-

      
   Type and Abatement Algorithm and MAY include the following    Type and Abatement Algorithm and MAY include the following

      
   information (the actual information stored is an implementation    information (the actual information stored is an implementation

      
   decision):    decision):

      
 

      
 

      
skipping to change at page 17, line 4 skipping to change at page 16, line 29

      
   Algorithm and per report-type.    Algorithm and per report-type.

      
 

      
   An OCS entry is identified by the tuple of Application-Id, Report-    An OCS entry is identified by the tuple of Application-Id, Report-

      
   Type and Abatement Algorithm and MAY include the following    Type and Abatement Algorithm and MAY include the following

      
   information (the actual information stored is an implementation    information (the actual information stored is an implementation

      
   decision):    decision):

      
 

      
   o  Sequence number    o  Sequence number

      
 

      
   o  Validity Duration    o  Validity Duration

      

      
                                                                          

      
   o  Expiration Time    o  Expiration Time

      
 

      
   o  Algorithm specific input data (for example, the Reduction    o  Algorithm specific input data (for example, the Reduction

      
      Percentage for the Loss Abatement Algorithm)       Percentage for the Loss Abatement Algorithm)

      
 

      

      
4.2.1.3.  Reacting Node Maintenance of Overload Control State 5.2.1.3.  Reacting Node Maintenance of Overload Control State

      
 

      
   When a reacting node receives an OC-OLR AVP, it MUST determine if it    When a reacting node receives an OC-OLR AVP, it MUST determine if it

      
   is for an existing or new overload condition.    is for an existing or new overload condition.

      
 

      
      Note: For the remainder of this section the term OLR refers to the       Note: For the remainder of this section the term OLR refers to the

      
      combination of the contents of the received OC-OLR AVP and the       combination of the contents of the received OC-OLR AVP and the

      
      abatement algorithm indicated in the received OC-Supported-       abatement algorithm indicated in the received OC-Supported-

      
      Features AVP.       Features AVP.

      
 

      
   When receiving an answer message with multiple OLRs of different    When receiving an answer message with multiple OLRs of different

      

      
   supported report types, a reporting node MUST process each received    supported report types, a reacting node MUST process each received

      
   OLR.    OLR.

      
 

      

      
   When receiving an OC-OLR AVPs with unknown values, a reacting node    When receiving an answer message with multiple OLRs and multiple of

      
   SHOULD be silently discarded by reacting nodes and the event SHOULD    the OLRs are of the same supported report types, a reacting node

      
   be logged.    SHOULD ignore the duplicated OLRs.

      
 

      
    A reacting node SHOULD ignore an OC-OLR with a OC-Report-Type AVP

      
    that contains an unrecognized value.

      
 

      
   The OLR is for an existing overload condition if a reacting node has    The OLR is for an existing overload condition if a reacting node has

      
   an OCS that matches the received OLR.    an OCS that matches the received OLR.

      
 

      
   For a host-report this means it matches the application-id and the    For a host-report this means it matches the application-id and the

      
   host's DiameterIdentity in an existing host OCS entry.    host's DiameterIdentity in an existing host OCS entry.

      
 

      
   For a realm-report this means it matches the application-id and the    For a realm-report this means it matches the application-id and the

      
   realm in an existing realm OCS entry.    realm in an existing realm OCS entry.

      
 

      
 

      
skipping to change at page 18, line 28 skipping to change at page 18, line 9

      
   reacting node MUST update the OCS entry as being expired.    reacting node MUST update the OCS entry as being expired.

      
 

      
      Note: It is not necessarily appropriate to delete the OCS entry,       Note: It is not necessarily appropriate to delete the OCS entry,

      
      as there is recommended behavior that the reacting node slowly       as there is recommended behavior that the reacting node slowly

      
      returns to full traffic when ending an overload abatement period.       returns to full traffic when ending an overload abatement period.

      
 

      
   The reacting node does not delete an OCS when receiving an answer    The reacting node does not delete an OCS when receiving an answer

      
   message that does not contain an OC-OLR AVP (i.e. absence of OLR    message that does not contain an OC-OLR AVP (i.e. absence of OLR

      
   means "no change").    means "no change").

      
 

      

      
4.2.1.4.  Reporting Node Maintenance of Overload Control State 5.2.1.4.  Reporting Node Maintenance of Overload Control State

      
 

      
   A reporting node SHOULD create a new OCS entry when entering an    A reporting node SHOULD create a new OCS entry when entering an

      
   overload condition.    overload condition.

      
 

      
      Note: If a reporting node knows through absence of the OC-       Note: If a reporting node knows through absence of the OC-

      
      Supported-Features AVP in received messages that there are no       Supported-Features AVP in received messages that there are no

      
      reacting nodes supporting DOIC then the reporting node can choose       reacting nodes supporting DOIC then the reporting node can choose

      
      to not create OCS entries.       to not create OCS entries.

      
 

      
   When generating a new OCS entry the sequence number SHOULD be set to    When generating a new OCS entry the sequence number SHOULD be set to

      
 

      
skipping to change at page 19, line 18 skipping to change at page 18, line 46

      
      For instance, if a reporting node wishes to instruct reacting       For instance, if a reporting node wishes to instruct reacting

      
      nodes to continue overload abatement for a longer period of time       nodes to continue overload abatement for a longer period of time

      
      than originally communicated.  This also applies if the reporting       than originally communicated.  This also applies if the reporting

      
      node wishes to shorten the period of time that overload abatement       node wishes to shorten the period of time that overload abatement

      
      is to continue.       is to continue.

      
 

      
   A reporting node MUST NOT update the abatement algorithm in an active    A reporting node MUST NOT update the abatement algorithm in an active

      
   OCS entry.    OCS entry.

      
 

      
   A reporting node MUST update an OCS entry when it wishes to adjust    A reporting node MUST update an OCS entry when it wishes to adjust

      

      
   any abatement algorithm specific parameters, including the reduction    any abatement algorithm specific parameters, including, for example,

      
   percentage used for the Loss abatement algorithm.    the reduction percentage used for the Loss abatement algorithm.

      
 

      
      For instance, if a reporting node wishes to change the reduction       For instance, if a reporting node wishes to change the reduction

      
      percentage either higher, if the overload condition has worsened,       percentage either higher, if the overload condition has worsened,

      
      or lower, if the overload condition has improved, then the       or lower, if the overload condition has improved, then the

      
      reporting node would update the appropriate OCS entry.       reporting node would update the appropriate OCS entry.

      
 

      

      
   A reporting node MUST update the sequence number associated with the    A reporting node MUST increment the sequence number associated with

      
   OCS entry anytime the contents of the OCS entry are changed.  This    the OCS entry anytime the contents of the OCS entry are changed.

      
   will result in a new sequence number being sent to reacting nodes,    This will result in a new sequence number being sent to reacting

      
   instructing reacting nodes to process the OC-OLR AVP.    nodes, instructing reacting nodes to process the OC-OLR AVP.

      
 

      
   A reporting node SHOULD update an OCS entry with a validity duration    A reporting node SHOULD update an OCS entry with a validity duration

      
   of zero ("0") when the overload condition ends.    of zero ("0") when the overload condition ends.

      
 

      
      Note: If a reporting node knows that the OCS entries in the       Note: If a reporting node knows that the OCS entries in the

      
      reacting nodes are near expiration then the reporting node might       reacting nodes are near expiration then the reporting node might

      
      decide not to send an OLR with a validity duration of zero.       decide not to send an OLR with a validity duration of zero.

      
 

      
   A reporting node MUST keep an OCS entry with a validity duration of    A reporting node MUST keep an OCS entry with a validity duration of

      
   zero ("0") for a period of time long enough to ensure that any non-    zero ("0") for a period of time long enough to ensure that any non-

      
   expired reacting node's OCS entry created as a result of the overload    expired reacting node's OCS entry created as a result of the overload

      
   condition in the reporting node is deleted.    condition in the reporting node is deleted.

      
 

      

      
4.2.2.  Reacting Node Behavior 5.2.2.  Reacting Node Behavior

      
 

      
   When a reacting node sends a request it MUST determine if that    When a reacting node sends a request it MUST determine if that

      
   request matches an active OCS.    request matches an active OCS.

      
 

      
   If the request matches an active OCS then the reacting node MUST use    If the request matches an active OCS then the reacting node MUST use

      
   the overload abatement algorithm indicated in the OCS to determine if    the overload abatement algorithm indicated in the OCS to determine if

      
   the request is to receive overload abatement treatment.    the request is to receive overload abatement treatment.

      
 

      
   For the Loss abatement algorithm defined in this specification, see    For the Loss abatement algorithm defined in this specification, see

      

      
   Section 5 for the overload abatement algorithm logic applied.    Section 6 for the overload abatement algorithm logic applied.

      
 

      
   If the overload abatement algorithm selects the request for overload    If the overload abatement algorithm selects the request for overload

      
   abatement treatment then the reacting node MUST apply overload    abatement treatment then the reacting node MUST apply overload

      
   abatement treatment on the request.  The abatement treatment applied    abatement treatment on the request.  The abatement treatment applied

      
   depends on the context of the request.    depends on the context of the request.

      
 

      

      
   If the request is a host-routed request then the reacting node SHOULD    If diversion abatement treatment is possible (i.e. a different path

      
   apply throttling abatement treatment to the request.    for the request can be selected where the overloaded node is not part

      
                                                                             of the different path), then the reacting node SHOULD apply diversion

      
   If the request is a realm-routed request then the reacting node    abatement treatment to the request.  Otherwise the reacting node

      
   SHOULD apply diversion abatement treatment to the request.    SHOULD apply throttling abatement treatment to the request.

      
 

      
   If the overload abatement treatment results in throttling of the    If the overload abatement treatment results in throttling of the

      
   request and if the reacting node is an agent then the agent MUST send    request and if the reacting node is an agent then the agent MUST send

      

      
   an appropriate error as defined in Section 7.    an appropriate error as defined in Section 8.

      
 

      

      
   The behavior of reacting nodes that are Diameter endpoints when    Diameter endpoints that throttle requests need to do so according to

      
   throttling requests depends on the application and is outside the    the rules of the client application.  Those rules will vary by

      
   scope of this specification.    application, and are beyond the scope of this document.

      
 

      
   In the case that the OCS entry indicated no traffic was to be sent to    In the case that the OCS entry indicated no traffic was to be sent to

      
   the overloaded entity and the validity duration expires then overload    the overloaded entity and the validity duration expires then overload

      
   abatement associated with the overload report MUST be ended in a    abatement associated with the overload report MUST be ended in a

      
   controlled fashion.    controlled fashion.

      
 

      

      
4.2.3.  Reporting Node Behavior 5.2.3.  Reporting Node Behavior

      
 

      
   If there is an active OCS entry then a reporting node SHOULD include    If there is an active OCS entry then a reporting node SHOULD include

      

      
   the OC-OLR AVP in all answer messages to requests that contain the    the OC-OLR AVP in all answers to requests that contain the OC-

      
   OC-Supported-Features AVP and that match the active OCS entry.    Supported-Features AVP and that match the active OCS entry.

      
 

      
      Note: A request matches if the application-id in the request       Note: A request matches if the application-id in the request

      
      matches the application-id in any active OCS entry and if the       matches the application-id in any active OCS entry and if the

      
      report-type in the OCS entry matches a report-type supported by       report-type in the OCS entry matches a report-type supported by

      
      the reporting node as indicated in the OC-Supported-Features AVP.       the reporting node as indicated in the OC-Supported-Features AVP.

      
 

      
   The contents of the OC-OLR AVP depend on the selected algorithm.    The contents of the OC-OLR AVP depend on the selected algorithm.

      
 

      
   A reporting node MAY choose to not resend an overload report to a    A reporting node MAY choose to not resend an overload report to a

      
   reacting node if it can guarantee that this overload report is    reacting node if it can guarantee that this overload report is

      
 

      
skipping to change at page 21, line 15 skipping to change at page 20, line 41

      
      report.       report.

      
 

      
   A reporting node MUST NOT send overload reports of a type that has    A reporting node MUST NOT send overload reports of a type that has

      
   not been advertised as supported by the reacting node.    not been advertised as supported by the reacting node.

      
 

      
      Note: A reacting node implicitly advertises support for the host       Note: A reacting node implicitly advertises support for the host

      
      and realm report types by including the OC-Supported-Features AVP       and realm report types by including the OC-Supported-Features AVP

      
      in the request.  Support for other report types will be explicitly       in the request.  Support for other report types will be explicitly

      
      indicated by new feature bits in the OC-Feature-Vector AVP.       indicated by new feature bits in the OC-Feature-Vector AVP.

      
 

      

      
   A reporting node MAY rely on the OC-Validity-Duration AVP values for 

      
   the implicit overload control state cleanup on the reacting node. 

      
                                                                          

      
   A reporting node SHOULD explicitly indicate the end of an overload    A reporting node SHOULD explicitly indicate the end of an overload

      
   occurrence by sending a new OLR with OC-Validity-Duration set to a    occurrence by sending a new OLR with OC-Validity-Duration set to a

      
   value of zero ("0").  The reporting node SHOULD ensure that all    value of zero ("0").  The reporting node SHOULD ensure that all

      
   reacting nodes receive the updated overload report.    reacting nodes receive the updated overload report.

      
 

      

      
    A reporting node MAY rely on the OC-Validity-Duration AVP values for

      
    the implicit overload control state cleanup on the reacting node.

      
                                                                          

      
      Note: All OLRs sent have an expiration time calculated by adding       Note: All OLRs sent have an expiration time calculated by adding

      
      the validity-duration contained in the OLR to the time the message       the validity-duration contained in the OLR to the time the message

      
      was sent.  Transit time for the OLR can be safely ignored.  The       was sent.  Transit time for the OLR can be safely ignored.  The

      
      reporting node can ensure that all reacting nodes have received       reporting node can ensure that all reacting nodes have received

      
      the OLR by continuing to send it in answer messages until the       the OLR by continuing to send it in answer messages until the

      
      expiration time for all OLRs sent for that overload condition have       expiration time for all OLRs sent for that overload condition have

      
      expired.       expired.

      
 

      
   When a reporting node sends an OLR, it effectively delegates any    When a reporting node sends an OLR, it effectively delegates any

      
   necessary throttling to downstream nodes.  If the reporting node also    necessary throttling to downstream nodes.  If the reporting node also

      
 

      
skipping to change at page 22, line 5 skipping to change at page 21, line 30

      
   for reasons other than overload.  For example, an agent or server    for reasons other than overload.  For example, an agent or server

      
   might have a configured rate limit for each client, and throttle    might have a configured rate limit for each client, and throttle

      
   requests that exceed that limit, even if such requests had already    requests that exceed that limit, even if such requests had already

      
   been candidates for throttling by downstream nodes.  The reporting    been candidates for throttling by downstream nodes.  The reporting

      
   node also has the option to send new OLRs requesting greater    node also has the option to send new OLRs requesting greater

      
   reductions in traffic, reducing the need for local throttling.    reductions in traffic, reducing the need for local throttling.

      
 

      
   A reporting node SHOULD decrease requested overload abatement    A reporting node SHOULD decrease requested overload abatement

      
   treatment in a controlled fashion to avoid oscillations in traffic.    treatment in a controlled fashion to avoid oscillations in traffic.

      
 

      

      
4.3.  Protocol Extensibility       For example, it might wait some period of time after overload ends

      
       before terminating the OLR, or it might send a series of OLRs

      
       indicating progressively less overload severity.

      
 

      
 5.3.  Protocol Extensibility

      
 

      
   The DOIC solution can be extended.  Types of potential extensions    The DOIC solution can be extended.  Types of potential extensions

      
   include new traffic abatement algorithms, new report types or other    include new traffic abatement algorithms, new report types or other

      
   new functionality.    new functionality.

      
 

      
   When defining a new extension that requires new normative behavior,    When defining a new extension that requires new normative behavior,

      
   the specification MUST define a new feature for the OC-Feature-    the specification MUST define a new feature for the OC-Feature-

      
   Vector.  This feature bit is used to communicate support for the new    Vector.  This feature bit is used to communicate support for the new

      
   feature.    feature.

      
 

      
   The extension MAY define new AVPs for use in DOIC Capability    The extension MAY define new AVPs for use in DOIC Capability

      
   Announcement and for use in DOIC Overload reporting.  These new AVPs    Announcement and for use in DOIC Overload reporting.  These new AVPs

      
   SHOULD be defined to be extensions to the OC-Supported-Features or    SHOULD be defined to be extensions to the OC-Supported-Features or

      
   OC-OLR AVPs defined in this document.    OC-OLR AVPs defined in this document.

      
 

      
   [RFC6733] defined Grouped AVP extension mechanisms apply.  This    [RFC6733] defined Grouped AVP extension mechanisms apply.  This

      
   allows, for example, defining a new feature that is mandatory to be    allows, for example, defining a new feature that is mandatory to be

      
   understood even when piggybacked on an existing application.    understood even when piggybacked on an existing application.

      
 

      

      
   The handling of feature bits in the OC-Feature-Vector AVP that are 

      
   not associated with overload abatement algorithms MUST be specified 

      
   by the extensions that define the features. 

      
                                                                          

      
   When defining new report type values, the corresponding specification    When defining new report type values, the corresponding specification

      
   MUST define the semantics of the new report types and how they affect    MUST define the semantics of the new report types and how they affect

      

      
   the OC-OLR AVP handling.  The specification MUST also reserve a    the OC-OLR AVP handling.

      
   corresponding new feature bit in the OC-Feature-Vector AVP. 

      
 

      
   The OC-OLR AVP can be expanded with optional sub-AVPs only if a    The OC-OLR AVP can be expanded with optional sub-AVPs only if a

      
   legacy DOIC implementation can safely ignore them without breaking    legacy DOIC implementation can safely ignore them without breaking

      

      
   backward compatibility for the given OC-Report-Type AVP value.  If    backward compatibility for the given OC-Report-Type AVP value.

      
   the new sub-AVPs imply new semantics for handling the indicated 

      
   report type, then a new OC-Report-Type AVP value MUST be defined. 

      
 

      
   Documents that introduce new report types MUST describe any    Documents that introduce new report types MUST describe any

      
   limitations on their use across non-supporting agents.    limitations on their use across non-supporting agents.

      
 

      

      
    As with any Diameter specification, RFC6733 requires all new AVPs to

      
    be registered with IANA.  See Section 9 for the required procedures.

      
   New features (feature bits in the OC-Feature-Vector AVP) and report    New features (feature bits in the OC-Feature-Vector AVP) and report

      

      
   types (in the OC-Report-Type AVP) MUST be registered with IANA.  As    types (in the OC-Report-Type AVP) MUST be registered with IANA.

      
   with any Diameter specification, RFC6733 requires all new AVPs to be 

      
   registered with IANA.  See Section 8 for the required procedures. 

      
 

      

      
5.  Loss Algorithm 6.  Loss Algorithm

      
 

      
   This section documents the Diameter overload loss abatement    This section documents the Diameter overload loss abatement

      
   algorithm.    algorithm.

      
 

      

      
5.1.  Overview 6.1.  Overview

      
 

      
   The DOIC specification supports the ability for multiple overload    The DOIC specification supports the ability for multiple overload

      
   abatement algorithms to be specified.  The abatement algorithm used    abatement algorithms to be specified.  The abatement algorithm used

      
   for any instance of overload is determined by the Diameter Overload    for any instance of overload is determined by the Diameter Overload

      

      
   Capability Announcement process documented in Section 4.1.    Capability Announcement process documented in Section 5.1.

      
 

      
   The loss algorithm described in this section is the default algorithm    The loss algorithm described in this section is the default algorithm

      
   that must be supported by all Diameter nodes that support DOIC.    that must be supported by all Diameter nodes that support DOIC.

      
 

      
   The loss algorithm is designed to be a straightforward and stateless    The loss algorithm is designed to be a straightforward and stateless

      
   overload abatement algorithm.  It is used by reporting nodes to    overload abatement algorithm.  It is used by reporting nodes to

      
   request a percentage reduction in the amount of traffic sent.  The    request a percentage reduction in the amount of traffic sent.  The

      
   traffic impacted by the requested reduction depends on the type of    traffic impacted by the requested reduction depends on the type of

      
   overload report.    overload report.

      
 

      

      
   Reporting nodes use a strategy of applying abatement logic to the    Reporting nodes request the stateless reduction of the number of

      
   requested percentage of request messages sent (or handled in the case    requests by an indicated percentage.  This percentage reduction is in

      
   of agents) by the reacting node that are impacted by the overload    comparison to the number of messages the node otherwise would send,

      
   report.    regardless of how many requests the node might have sent in the past.

      
 

      
   From a conceptual level, the logic at the reacting node could be    From a conceptual level, the logic at the reacting node could be

      
   outlined as follows.    outlined as follows.

      
 

      
   1.  An overload report is received and the associated OCS is either    1.  An overload report is received and the associated OCS is either

      
       saved or updated (if required) by the reacting node.        saved or updated (if required) by the reacting node.

      
 

      
   2.  A new Diameter request is generated by the application running on    2.  A new Diameter request is generated by the application running on

      
       the reacting node.        the reacting node.

      
 

      
 

      
skipping to change at page 23, line 47 skipping to change at page 23, line 23

      
       entry.        entry.

      
 

      
   4.  The reacting node determines if overload abatement treatment    4.  The reacting node determines if overload abatement treatment

      
       should be applied to the request.  One approach that could be        should be applied to the request.  One approach that could be

      
       taken for each request is to select a random number between 1 and        taken for each request is to select a random number between 1 and

      
       100.  If the random number is less than or equal to the indicated        100.  If the random number is less than or equal to the indicated

      
       reduction percentage then the request is given abatement        reduction percentage then the request is given abatement

      
       treatment, otherwise the request is given normal routing        treatment, otherwise the request is given normal routing

      
       treatment.        treatment.

      
 

      

      
5.2.  Reporting Node Behavior 6.2.  Reporting Node Behavior

      
 

      
   The method a reporting node uses to determine the amount of traffic    The method a reporting node uses to determine the amount of traffic

      
   reduction required to address an overload condition is an    reduction required to address an overload condition is an

      
   implementation decision.    implementation decision.

      
 

      
   When a reporting node that has selected the loss abatement algorithm    When a reporting node that has selected the loss abatement algorithm

      
   determines the need to request a reduction in traffic, it includes an    determines the need to request a reduction in traffic, it includes an

      

      
   OC-OLR AVP in response messages as described in Section 4.2.3.    OC-OLR AVP in answer messages as described in Section 5.2.3.

      
 

      
   When sending the OC-OLR AVP, the reporting node MUST indicate a    When sending the OC-OLR AVP, the reporting node MUST indicate a

      
   percentage reduction in the OC-Reduction-Percentage AVP.    percentage reduction in the OC-Reduction-Percentage AVP.

      
 

      
   The reporting node MAY change the reduction percentage in subsequent    The reporting node MAY change the reduction percentage in subsequent

      
   overload reports.  When doing so the reporting node must conform to    overload reports.  When doing so the reporting node must conform to

      

      
   overload report handing specified in Section 4.2.3.    overload report handing specified in Section 5.2.3.

      
 

      

      
5.3.  Reacting Node Behavior 6.3.  Reacting Node Behavior

      
 

      
   The method a reacting node uses to determine which request messages    The method a reacting node uses to determine which request messages

      
   are given abatement treatment is an implementation decision.    are given abatement treatment is an implementation decision.

      
 

      
   When receiving an OC-OLR in an answer message where the algorithm    When receiving an OC-OLR in an answer message where the algorithm

      
   indicated in the OC-Supported-Features AVP is the loss algorithm, the    indicated in the OC-Supported-Features AVP is the loss algorithm, the

      
   reacting node MUST apply abatement treatment to the requested    reacting node MUST apply abatement treatment to the requested

      
   percentage of request messages sent.    percentage of request messages sent.

      
 

      
      Note: The loss algorithm is a stateless algorithm.  As a result,       Note: The loss algorithm is a stateless algorithm.  As a result,

      
 

      
skipping to change at page 24, line 38 skipping to change at page 24, line 13

      
      absolute reduction in traffic sent.  Rather, it guarantees that       absolute reduction in traffic sent.  Rather, it guarantees that

      
      the requested percentage of new requests will be given abatement       the requested percentage of new requests will be given abatement

      
      treatment.       treatment.

      
 

      
   When applying overload abatement treatment for the loss abatement    When applying overload abatement treatment for the loss abatement

      
   algorithm, the reacting node MUST abate the requested percentage of    algorithm, the reacting node MUST abate the requested percentage of

      
   requests that would have otherwise been sent to the reporting host or    requests that would have otherwise been sent to the reporting host or

      
   realm.    realm.

      
 

      
   If reacting node comes out of the 100 percent traffic reduction as a    If reacting node comes out of the 100 percent traffic reduction as a

      

      
   result of the overload report timing out, the following concerns are    result of the overload report timing out, the following procedures

      
   RECOMMENDED to be applied.  The reacting node sending the traffic    are RECOMMENDED to be applied.  The reacting node sending the traffic

      
   should be conservative and, for example, first send "probe" messages    should be conservative and, for example, first send "probe" messages

      
   to learn the overload condition of the overloaded node before    to learn the overload condition of the overloaded node before

      
   converging to any traffic amount/rate decided by the sender.  Similar    converging to any traffic amount/rate decided by the sender.  Similar

      
   concerns apply in all cases when the overload report times out unless    concerns apply in all cases when the overload report times out unless

      
   the previous overload report stated 0 percent reduction.    the previous overload report stated 0 percent reduction.

      
 

      

      
   If the reacting node does not receive an OLR in response to messages 

      
   sent to the formerly overloaded node then the reacting node SHOULD 

      
   slowly increase the rate of traffic sent to the overloaded node. 

      
 

      
   When an active overload report expires, it is suggested that the 

      
   reacting node progressively decrease the amount of traffic given 

      
   abatement treatment, until the reduction is completely removed and no 

      
   traffic is given abatement treatment. 

      
                                                                          

      
      The goal of this behavior is to reduce the probability of overload       The goal of this behavior is to reduce the probability of overload

      
      condition thrashing where an immediate transition from 100%       condition thrashing where an immediate transition from 100%

      
      reduction to 0% reduction results in the reporting node moving       reduction to 0% reduction results in the reporting node moving

      
      quickly back into an overload condition.       quickly back into an overload condition.

      
 

      

      
6.  Attribute Value Pairs    If the reacting node does not receive an OLR in answers received from

      
    the formerly overloaded node then the reacting node SHOULD slowly

      
    increase the rate of traffic sent to the overloaded node.

      
 

      
 7.  Attribute Value Pairs

      
 

      
   This section describes the encoding and semantics of the Diameter    This section describes the encoding and semantics of the Diameter

      
   Overload Indication Attribute Value Pairs (AVPs) defined in this    Overload Indication Attribute Value Pairs (AVPs) defined in this

      
   document.    document.

      
 

      

      
   A new application specification can incorporate the overload control 7.1.  OC-Supported-Features AVP

      
   mechanism specified in this document by making it mandatory to 

      
   implement for the application and referencing this specification 

      
   normatively.  It is the responsibility of the Diameter application 

      
   designers to define how overload control mechanisms works on that 

      
   application. 

      
 

      
6.1.  OC-Supported-Features AVP 

      
 

      
   The OC-Supported-Features AVP (AVP code TBD1) is of type Grouped and    The OC-Supported-Features AVP (AVP code TBD1) is of type Grouped and

      
   serves two purposes.  First, it announces a node's support for the    serves two purposes.  First, it announces a node's support for the

      
   DOIC solution in general.  Second, it contains the description of the    DOIC solution in general.  Second, it contains the description of the

      
   supported DOIC features of the sending node.  The OC-Supported-    supported DOIC features of the sending node.  The OC-Supported-

      
   Features AVP MUST be included in every Diameter request message a    Features AVP MUST be included in every Diameter request message a

      
   DOIC supporting node sends.    DOIC supporting node sends.

      
 

      
      OC-Supported-Features ::= < AVP Header: TBD1 >       OC-Supported-Features ::= < AVP Header: TBD1 >

      
                                [ OC-Feature-Vector ]                                 [ OC-Feature-Vector ]

      
                              * [ AVP ]                               * [ AVP ]

      
 

      

      
6.2.  OC-Feature-Vector AVP 7.2.  OC-Feature-Vector AVP

      
 

      

      
   The OC-Feature-Vector AVP (AVP code TBD6) is of type Unsigned64 and    The OC-Feature-Vector AVP (AVP code TBD2) is of type Unsigned64 and

      
   contains a 64 bit flags field of announced capabilities of a DOIC    contains a 64 bit flags field of announced capabilities of a DOIC

      
   node.  The value of zero (0) is reserved.    node.  The value of zero (0) is reserved.

      
 

      
   The OC-Feature-Vector sub-AVP is used to announce the DOIC features    The OC-Feature-Vector sub-AVP is used to announce the DOIC features

      
   supported by the DOIC node, in the form of a flag-bits field in which    supported by the DOIC node, in the form of a flag-bits field in which

      
   each bit announces one feature or capability supported by the node.    each bit announces one feature or capability supported by the node.

      
   The absence of the OC-Feature-Vector AVP in request messages    The absence of the OC-Feature-Vector AVP in request messages

      
   indicates that only the default traffic abatement algorithm described    indicates that only the default traffic abatement algorithm described

      
   in this specification is supported.  The absence of the OC- Feature-    in this specification is supported.  The absence of the OC- Feature-

      
   Vector AVP in answer messages indicates that the default traffic    Vector AVP in answer messages indicates that the default traffic

      
 

      
skipping to change at page 26, line 17 skipping to change at page 25, line 31

      
 

      
   The following capabilities are defined in this document:    The following capabilities are defined in this document:

      
 

      
   OLR_DEFAULT_ALGO (0x0000000000000001)    OLR_DEFAULT_ALGO (0x0000000000000001)

      
 

      
      When this flag is set by the a DOIC reacting node it means that       When this flag is set by the a DOIC reacting node it means that

      
      the default traffic abatement (loss) algorithm is supported.  When       the default traffic abatement (loss) algorithm is supported.  When

      
      this flag is set by a DOIC reporting node it means that the loss       this flag is set by a DOIC reporting node it means that the loss

      
      algorithm will be used for requested overload abatement.       algorithm will be used for requested overload abatement.

      
 

      

      
6.3.  OC-OLR AVP 7.3.  OC-OLR AVP

      
 

      

      
   The OC-OLR AVP (AVP code TBD2) is of type Grouped and contains the    The OC-OLR AVP (AVP code TBD3) is of type Grouped and contains the

      
   information necessary to convey an overload report on an overload    information necessary to convey an overload report on an overload

      

      
   condition at the reporting node.  The OC-OLR AVP does not explicitly    condition at the reporting node.  The application the OC-OLR AVP

      
   contain all information needed by the reacting node to decide whether    applies to is the same as the Application-Id found in the Diameter

      
   a subsequent request must undergo abatement using the selected    message header.  The host or realm the OC-OLR AVP concerns is

      
   abatement algorithm.  The value of the OC-Report-Type AVP within the    determined from the Origin-Host AVP and/or Origin-Realm AVP found in

      
   OC-OLR AVP indicates which implicit information is relevant for this    the encapsulating Diameter command.  The OC-OLR AVP is intended to be

      
   decision (see Section 6.6).  The application the OC-OLR AVP applies 

      
   to is the same as the Application-Id found in the Diameter message 

      
   header.  The host or realm the OC-OLR AVP concerns is determined from 

      
   the Origin-Host AVP and/or Origin-Realm AVP found in the 

      
   encapsulating Diameter command.  The OC-OLR AVP is intended to be 

      
   sent only by a reporting node.    sent only by a reporting node.

      
 

      
      OC-OLR ::= < AVP Header: TBD2 >       OC-OLR ::= < AVP Header: TBD2 >

      
                 < OC-Sequence-Number >                  < OC-Sequence-Number >

      
                 < OC-Report-Type >                  < OC-Report-Type >

      
                 [ OC-Reduction-Percentage ]                  [ OC-Reduction-Percentage ]

      
                 [ OC-Validity-Duration ]                  [ OC-Validity-Duration ]

      
               * [ AVP ]                * [ AVP ]

      
 

      

      
6.4.  OC-Sequence-Number AVP 7.4.  OC-Sequence-Number AVP

      
 

      

      
   The OC-Sequence-Number AVP (AVP code TBD3) is of type Unsigned64.    The OC-Sequence-Number AVP (AVP code TBD4) is of type Unsigned64.

      
   Its usage in the context of overload control is described in    Its usage in the context of overload control is described in

      

      
   Section 4.2.    Section 5.2.

      
 

      
   From the functionality point of view, the OC-Sequence-Number AVP is    From the functionality point of view, the OC-Sequence-Number AVP is

      
   used as a non-volatile increasing counter for a sequence of overload    used as a non-volatile increasing counter for a sequence of overload

      

      
   reports between two DOIC nodes for the same overload occurrence.  The    reports between two DOIC nodes for the same overload occurrence.

      
   sequence number is only required to be unique between two DOIC nodes. 

      
   Sequence numbers are treated in a uni-directional manner, i.e. two    Sequence numbers are treated in a uni-directional manner, i.e. two

      
   sequence numbers on each direction between two DOIC nodes are not    sequence numbers on each direction between two DOIC nodes are not

      
   related or correlated.    related or correlated.

      
 

      

      
6.5.  OC-Validity-Duration AVP 7.5.  OC-Validity-Duration AVP

      
 

      

      
   The OC-Validity-Duration AVP (AVP code TBD4) is of type Unsigned32    The OC-Validity-Duration AVP (AVP code TBD5) is of type Unsigned32

      
   and indicates in milliseconds the validity time of the overload    and indicates in milliseconds the validity time of the overload

      
   report.  The number of milliseconds is measured after reception of    report.  The number of milliseconds is measured after reception of

      
   the first OC-OLR AVP with a given value of OC-Sequence-Number AVP.    the first OC-OLR AVP with a given value of OC-Sequence-Number AVP.

      
   The default value for the OC-Validity-Duration AVP is 30000 (i.e.; 30    The default value for the OC-Validity-Duration AVP is 30000 (i.e.; 30

      
   seconds).  When the OC-Validity-Duration AVP is not present in the    seconds).  When the OC-Validity-Duration AVP is not present in the

      
   OC-OLR AVP, the default value applies.    OC-OLR AVP, the default value applies.

      
 

      

      
6.6.  OC-Report-Type AVP 7.6.  OC-Report-Type AVP

      
 

      

      
   The OC-Report-Type AVP (AVP code TBD5) is of type Enumerated.  The    The OC-Report-Type AVP (AVP code TBD6) is of type Enumerated.  The

      
   value of the AVP describes what the overload report concerns.  The    value of the AVP describes what the overload report concerns.  The

      
   following values are initially defined:    following values are initially defined:

      
 

      
   HOST_REPORT 0  The overload report is for a host.  Overload abatement    HOST_REPORT 0  The overload report is for a host.  Overload abatement

      
      treatment applies to host-routed requests.       treatment applies to host-routed requests.

      
 

      
   REALM_REPORT 1  The overload report is for a realm.  Overload    REALM_REPORT 1  The overload report is for a realm.  Overload

      
      abatement treatment applies to realm-routed requests.       abatement treatment applies to realm-routed requests.

      
 

      

      
6.7.  OC-Reduction-Percentage AVP 7.7.  OC-Reduction-Percentage AVP

      
 

      

      
   The OC-Reduction-Percentage AVP (AVP code TBD8) is of type Unsigned32    The OC-Reduction-Percentage AVP (AVP code TBD7) is of type Unsigned32

      
   and describes the percentage of the traffic that the sender is    and describes the percentage of the traffic that the sender is

      
   requested to reduce, compared to what it otherwise would send.  The    requested to reduce, compared to what it otherwise would send.  The

      
   OC-Reduction-Percentage AVP applies to the default (loss) algorithm    OC-Reduction-Percentage AVP applies to the default (loss) algorithm

      
   specified in this specification.  However, the AVP can be reused for    specified in this specification.  However, the AVP can be reused for

      
   future abatement algorithms, if its semantics fit into the new    future abatement algorithms, if its semantics fit into the new

      
   algorithm.    algorithm.

      
 

      
   The value of the Reduction-Percentage AVP is between zero (0) and one    The value of the Reduction-Percentage AVP is between zero (0) and one

      
   hundred (100).  Values greater than 100 are ignored.  The value of    hundred (100).  Values greater than 100 are ignored.  The value of

      
   100 means that all traffic is to be throttled, i.e. the reporting    100 means that all traffic is to be throttled, i.e. the reporting

      
   node is under a severe load and ceases to process any new messages.    node is under a severe load and ceases to process any new messages.

      
   The value of 0 means that the reporting node is in a stable state and    The value of 0 means that the reporting node is in a stable state and

      
   has no need for the reacting node to apply any traffic abatement.    has no need for the reacting node to apply any traffic abatement.

      

      
   The default value of the OC-Reduction-Percentage AVP is 0.  When the 

      
   OC-Reduction-Percentage AVP is not present in the overload report, 

      
   the default value applies. 

      
 

      

      
6.8.  Attribute Value Pair flag rules 7.8.  Attribute Value Pair flag rules

      
 

      
                                                         +---------+                                                          +---------+

      
                                                         |AVP flag |                                                          |AVP flag |

      
                                                         |rules    |                                                          |rules    |

      
                                                         +----+----+                                                          +----+----+

      
                              AVP   Section              |    |MUST|                               AVP   Section              |    |MUST|

      
       Attribute Name         Code  Defined  Value Type  |MUST| NOT|        Attribute Name         Code  Defined  Value Type  |MUST| NOT|

      
      +--------------------------------------------------+----+----+       +--------------------------------------------------+----+----+

      
      |OC-Supported-Features  TBD1  6.1      Grouped     |    | V  |       |OC-Supported-Features  TBD1  6.1      Grouped     |    | V  |

      
      +--------------------------------------------------+----+----+       +--------------------------------------------------+----+----+

      

      
      |OC-OLR                 TBD2  6.3      Grouped     |    | V  |       |OC-Feature-Vector      TBD2  6.2      Unsigned64  |    | V  |

      
      +--------------------------------------------------+----+----+       +--------------------------------------------------+----+----+

      

      
      |OC-Sequence-Number     TBD3  6.4      Unsigned64  |    | V  |       |OC-OLR                 TBD3  6.3      Grouped     |    | V  |

      
      +--------------------------------------------------+----+----+       +--------------------------------------------------+----+----+

      

      
      |OC-Validity-Duration   TBD4  6.5      Unsigned32  |    | V  |       |OC-Sequence-Number     TBD4  6.4      Unsigned64  |    | V  |

      
      +--------------------------------------------------+----+----+       +--------------------------------------------------+----+----+

      

      
      |OC-Report-Type         TBD5  6.6      Enumerated  |    | V  |       |OC-Validity-Duration   TBD5  6.5      Unsigned32  |    | V  |

      
      +--------------------------------------------------+----+----+       +--------------------------------------------------+----+----+

      

      
      |OC-Reduction                                      |    |    |       |OC-Report-Type         TBD6  6.6      Enumerated  |    | V  |

      
      |  -Percentage          TBD8  6.7      Unsigned32  |    | V  | 

      
      +--------------------------------------------------+----+----+       +--------------------------------------------------+----+----+

      

      
      |OC-Feature-Vector      TBD6  6.2      Unsigned64  |    | V  |       |OC-Reduction                                      |    |    |

      
       |  -Percentage          TBD7  6.7      Unsigned32  |    | V  |

      
      +--------------------------------------------------+----+----+       +--------------------------------------------------+----+----+

      
 

      
   As described in the Diameter base protocol [RFC6733], the M-bit usage    As described in the Diameter base protocol [RFC6733], the M-bit usage

      
   for a given AVP in a given command may be defined by the application.    for a given AVP in a given command may be defined by the application.

      
 

      

      
7.  Error Response Codes 8.  Error Response Codes

      
 

      
   When a DOIC node rejects a Diameter request due to overload, the DOIC    When a DOIC node rejects a Diameter request due to overload, the DOIC

      
   node MUST select an appropriate error response code.  This    node MUST select an appropriate error response code.  This

      
   determination is made based on the probability of the request    determination is made based on the probability of the request

      
   succeeding if retried on a different path.    succeeding if retried on a different path.

      
 

      
   A reporting node rejecting a Diameter request due to an overload    A reporting node rejecting a Diameter request due to an overload

      
   condition SHOULD send a DIAMETER_TOO_BUSY error response, if it can    condition SHOULD send a DIAMETER_TOO_BUSY error response, if it can

      
   assume that the same request may succeed on a different path.    assume that the same request may succeed on a different path.

      
 

      
 

      
skipping to change at page 29, line 20 skipping to change at page 28, line 24

      
      reporting node can assume that retrying the request would result       reporting node can assume that retrying the request would result

      
      in it coming to the same reporting node.       in it coming to the same reporting node.

      
      DIAMETER_UNABLE_TO_COMPLY would be sent in this case.       DIAMETER_UNABLE_TO_COMPLY would be sent in this case.

      
 

      
      A second example is when an agent that supports the DOIC solution       A second example is when an agent that supports the DOIC solution

      
      is performing the role of a reacting node for a non supporting       is performing the role of a reacting node for a non supporting

      
      client.  Requests that are rejected as a result of DOIC throttling       client.  Requests that are rejected as a result of DOIC throttling

      
      by the agent in this scenario would generally be rejected with a       by the agent in this scenario would generally be rejected with a

      
      DIAMETER_UNABLE_TO_COMPLY response code.       DIAMETER_UNABLE_TO_COMPLY response code.

      
 

      

      
8.  IANA Considerations 9.  IANA Considerations

      
 

      

      
8.1.  AVP codes 9.1.  AVP codes

      
 

      

      
   New AVPs defined by this specification are listed in Section 6.  All    New AVPs defined by this specification are listed in Section 7.  All

      
   AVP codes are allocated from the 'Authentication, Authorization, and    AVP codes are allocated from the 'Authentication, Authorization, and

      
   Accounting (AAA) Parameters' AVP Codes registry.    Accounting (AAA) Parameters' AVP Codes registry.

      
 

      

      
8.2.  New registries 9.2.  New registries

      
 

      
   Two new registries are needed under the 'Authentication,    Two new registries are needed under the 'Authentication,

      
   Authorization, and Accounting (AAA) Parameters' registry.    Authorization, and Accounting (AAA) Parameters' registry.

      
 

      
   A new "Overload Control Feature Vector" registry is required.  The    A new "Overload Control Feature Vector" registry is required.  The

      
   registry must contain the following:    registry must contain the following:

      
 

      
      Feature Vector Value       Feature Vector Value

      
 

      
      Specification - the specification that defines the new value.       Specification - the specification that defines the new value.

      
 

      

      
   See Section 6.2 for the initial Feature Vector Value in the registry.    See Section 7.2 for the initial Feature Vector Value in the registry.

      
   This specification is the specification defining the value.  New    This specification is the specification defining the value.  New

      
   values can be added into the registry using the Specification    values can be added into the registry using the Specification

      
   Required policy.  [RFC5226].    Required policy.  [RFC5226].

      
 

      
   A new "Overload Report Type" registry is required.  The registry must    A new "Overload Report Type" registry is required.  The registry must

      
   contain the following:    contain the following:

      
 

      
      Report Type Value       Report Type Value

      

      
                                                                          

      
      Specification - the specification that defines the new value.       Specification - the specification that defines the new value.

      
 

      

      
   See Section 6.6 for the initial assignment in the registry.  New    See Section 7.6 for the initial assignment in the registry.  New

      
   types can be added using the Specification Required policy [RFC5226].    types can be added using the Specification Required policy [RFC5226].

      
 

      

      
9.  Security Considerations 10.  Security Considerations

      
 

      
   DOIC gives Diameter nodes the ability to request that downstream    DOIC gives Diameter nodes the ability to request that downstream

      
   nodes send fewer Diameter requests.  Nodes do this by exchanging    nodes send fewer Diameter requests.  Nodes do this by exchanging

      
   overload reports that directly effect this reduction.  This exchange    overload reports that directly effect this reduction.  This exchange

      
   is potentially subject to multiple methods of attack, and has the    is potentially subject to multiple methods of attack, and has the

      
   potential to be used as a Denial-of-Service (DoS) attack vector.    potential to be used as a Denial-of-Service (DoS) attack vector.

      
 

      
   Overload reports may contain information about the topology and    Overload reports may contain information about the topology and

      
   current status of a Diameter network.  This information is    current status of a Diameter network.  This information is

      
   potentially sensitive.  Network operators may wish to control    potentially sensitive.  Network operators may wish to control

      
   disclosure of overload reports to unauthorized parties to avoid its    disclosure of overload reports to unauthorized parties to avoid its

      
   use for competitive intelligence or to target attacks.    use for competitive intelligence or to target attacks.

      
 

      
   Diameter does not include features to provide end-to-end    Diameter does not include features to provide end-to-end

      
   authentication, integrity protection, or confidentiality.  This may    authentication, integrity protection, or confidentiality.  This may

      
   cause complications when sending overload reports between non-    cause complications when sending overload reports between non-

      
   adjacent nodes.    adjacent nodes.

      
 

      

      
9.1.  Potential Threat Modes 10.1.  Potential Threat Modes

      
 

      
   The Diameter protocol involves transactions in the form of requests    The Diameter protocol involves transactions in the form of requests

      
   and answers exchanged between clients and servers.  These clients and    and answers exchanged between clients and servers.  These clients and

      
   servers may be peers, that is, they may share a direct transport    servers may be peers, that is, they may share a direct transport

      
   (e.g.  TCP or SCTP) connection, or the messages may traverse one or    (e.g.  TCP or SCTP) connection, or the messages may traverse one or

      
   more intermediaries, known as Diameter Agents.  Diameter nodes use    more intermediaries, known as Diameter Agents.  Diameter nodes use

      
   TLS, DTLS, or IPsec to authenticate peers, and to provide    TLS, DTLS, or IPsec to authenticate peers, and to provide

      
   confidentiality and integrity protection of traffic between peers.    confidentiality and integrity protection of traffic between peers.

      
   Nodes can make authorization decisions based on the peer identities    Nodes can make authorization decisions based on the peer identities

      
   authenticated at the transport layer.    authenticated at the transport layer.

      
 

      
skipping to change at page 31, line 31 skipping to change at page 30, line 33

      
   before acting on the report or forwarding the report to other peers.    before acting on the report or forwarding the report to other peers.

      
   For example, an overload report from a peer that applies to a realm    For example, an overload report from a peer that applies to a realm

      
   not handled by that peer is suspect.    not handled by that peer is suspect.

      
 

      
      This attack is partially mitigated by the fact that the       This attack is partially mitigated by the fact that the

      
      application, as well as host and realm, for a given OLR is       application, as well as host and realm, for a given OLR is

      
      determined implicitly by respective AVPs in the enclosing answer.       determined implicitly by respective AVPs in the enclosing answer.

      
      If a reporting node modifies any of those AVPs, the enclosing       If a reporting node modifies any of those AVPs, the enclosing

      
      transaction will also be affected.       transaction will also be affected.

      
 

      

      
9.2.  Denial of Service Attacks 10.2.  Denial of Service Attacks

      
 

      
   Diameter overload reports, especially realm-reports, can cause a node    Diameter overload reports, especially realm-reports, can cause a node

      
   to cease sending some or all Diameter requests for an extended    to cease sending some or all Diameter requests for an extended

      
   period.  This makes them a tempting vector for DoS attacks.    period.  This makes them a tempting vector for DoS attacks.

      
   Furthermore, since Diameter is almost always used in support of other    Furthermore, since Diameter is almost always used in support of other

      
   protocols, a DoS attack on Diameter is likely to impact those    protocols, a DoS attack on Diameter is likely to impact those

      
   protocols as well.  Therefore, Diameter nodes MUST NOT honor or    protocols as well.  Therefore, Diameter nodes MUST NOT honor or

      
   forward OLRs received from peers that are not trusted to send them.    forward OLRs received from peers that are not trusted to send them.

      
 

      
   An attacker might use the information in an OLR to assist in DoS    An attacker might use the information in an OLR to assist in DoS

      
   attacks.  For example, an attacker could use information about    attacks.  For example, an attacker could use information about

      
   current overload conditions to time an attack for maximum effect, or    current overload conditions to time an attack for maximum effect, or

      
   use subsequent overload reports as a feedback mechanism to learn the    use subsequent overload reports as a feedback mechanism to learn the

      
   results of a previous or ongoing attack.  Operators need the ability    results of a previous or ongoing attack.  Operators need the ability

      
   to ensure that OLRs are not leaked to untrusted parties.    to ensure that OLRs are not leaked to untrusted parties.

      
 

      

      
9.3.  Non-Compliant Nodes 10.3.  Non-Compliant Nodes

      
 

      
   In the absence of an overload control mechanism, Diameter nodes need    In the absence of an overload control mechanism, Diameter nodes need

      
   to implement strategies to protect themselves from floods of    to implement strategies to protect themselves from floods of

      
   requests, and to make sure that a disproportionate load from one    requests, and to make sure that a disproportionate load from one

      
   source does not prevent other sources from receiving service.  For    source does not prevent other sources from receiving service.  For

      
   example, a Diameter server might throttle a certain percentage of    example, a Diameter server might throttle a certain percentage of

      
   requests from sources that exceed certain limits.  Overload control    requests from sources that exceed certain limits.  Overload control

      
   can be thought of as an optimization for such strategies, where    can be thought of as an optimization for such strategies, where

      
   downstream nodes never send the excess requests in the first place.    downstream nodes never send the excess requests in the first place.

      
   However, the presence of an overload control mechanism does not    However, the presence of an overload control mechanism does not

      
 

      
skipping to change at page 32, line 28 skipping to change at page 31, line 28

      
   When a Diameter node sends an overload report, it cannot assume that    When a Diameter node sends an overload report, it cannot assume that

      
   all nodes will comply, even if they indicate support for DOIC.  A    all nodes will comply, even if they indicate support for DOIC.  A

      
   non-compliant node might continue to send requests with no reduction    non-compliant node might continue to send requests with no reduction

      
   in load.  Such non-compliance could be done accidentally, or    in load.  Such non-compliance could be done accidentally, or

      
   maliciously to gain an unfair advantage over compliant nodes.    maliciously to gain an unfair advantage over compliant nodes.

      
   Requirement 28 [RFC7068] indicates that the overload control solution    Requirement 28 [RFC7068] indicates that the overload control solution

      
   cannot assume that all Diameter nodes in a network are trusted, and    cannot assume that all Diameter nodes in a network are trusted, and

      
   that malicious nodes not be allowed to take advantage of the overload    that malicious nodes not be allowed to take advantage of the overload

      
   control mechanism to get more than their fair share of service.    control mechanism to get more than their fair share of service.

      
 

      

      
9.4.  End-to End-Security Issues 10.4.  End-to End-Security Issues

      
 

      
   The lack of end-to-end integrity features makes it difficult to    The lack of end-to-end integrity features makes it difficult to

      
   establish trust in overload reports received from non-adjacent nodes.    establish trust in overload reports received from non-adjacent nodes.

      
   Any agents in the message path may insert or modify overload reports.    Any agents in the message path may insert or modify overload reports.

      
   Nodes must trust that their adjacent peers perform proper checks on    Nodes must trust that their adjacent peers perform proper checks on

      
   overload reports from their peers, and so on, creating a transitive-    overload reports from their peers, and so on, creating a transitive-

      
   trust requirement extending for potentially long chains of nodes.    trust requirement extending for potentially long chains of nodes.

      
   Network operators must determine if this transitive trust requirement    Network operators must determine if this transitive trust requirement

      
   is acceptable for their deployments.  Nodes supporting Diameter    is acceptable for their deployments.  Nodes supporting Diameter

      
   overload control MUST give operators the ability to select which    overload control MUST give operators the ability to select which

      
   peers are trusted to deliver overload reports, and whether they are    peers are trusted to deliver overload reports, and whether they are

      
   trusted to forward overload reports from non-adjacent nodes.  DOIC    trusted to forward overload reports from non-adjacent nodes.  DOIC

      
   nodes MUST strip DOIC AVPs from messages received from peers that are    nodes MUST strip DOIC AVPs from messages received from peers that are

      
   not trusted for DOIC purposes.    not trusted for DOIC purposes.

      
 

      
   The lack of end-to-end confidentiality protection means that any    The lack of end-to-end confidentiality protection means that any

      
   Diameter agent in the path of an overload report can view the    Diameter agent in the path of an overload report can view the

      
   contents of that report.  In addition to the requirement to select    contents of that report.  In addition to the requirement to select

      
   which peers are trusted to send overload reports, operators MUST be    which peers are trusted to send overload reports, operators MUST be

      
   able to select which peers are authorized to receive reports.  A node    able to select which peers are authorized to receive reports.  A node

      

      
   MUST not send an overload report to a peer not authorized to receive    MUST NOT send an overload report to a peer not authorized to receive

      
   it.  Furthermore, an agent MUST remove any overload reports that    it.  Furthermore, an agent MUST remove any overload reports that

      
   might have been inserted by other nodes before forwarding a Diameter    might have been inserted by other nodes before forwarding a Diameter

      
   message to a peer that is not authorized to receive overload reports.    message to a peer that is not authorized to receive overload reports.

      
 

      
      A DOIC node cannot always automatically detect that a peer also       A DOIC node cannot always automatically detect that a peer also

      
      supports DOIC.  For example, a node might have a peer that is a       supports DOIC.  For example, a node might have a peer that is a

      
      non-supporting agent.  If nodes on the other side of that agent       non-supporting agent.  If nodes on the other side of that agent

      
      send OC-Supported-Features AVPs, the agent is likely to forward       send OC-Supported-Features AVPs, the agent is likely to forward

      
      them as unknown AVPs.  Messages received across the non-supporting       them as unknown AVPs.  Messages received across the non-supporting

      
      agent may be indistinguishable from messages received across a       agent may be indistinguishable from messages received across a

      
 

      
skipping to change at page 33, line 31 skipping to change at page 32, line 31

      
   adjacent nodes for overload control purposes.  Readers should be    adjacent nodes for overload control purposes.  Readers should be

      
   reminded, however, that the overload control mechanism encourages    reminded, however, that the overload control mechanism encourages

      
   Diameter agents to modify AVPs in, or insert additional AVPs into,    Diameter agents to modify AVPs in, or insert additional AVPs into,

      
   existing messages that are originated by other nodes.  If end-to-end    existing messages that are originated by other nodes.  If end-to-end

      
   security is enabled, there is a risk that such modification could    security is enabled, there is a risk that such modification could

      
   violate integrity protection.  The details of using any future    violate integrity protection.  The details of using any future

      
   Diameter end-to-end security mechanism with overload control will    Diameter end-to-end security mechanism with overload control will

      
   require careful consideration, and are beyond the scope of this    require careful consideration, and are beyond the scope of this

      
   document.    document.

      
 

      

      
10.  Contributors 11.  Contributors

      
 

      
   The following people contributed substantial ideas, feedback, and    The following people contributed substantial ideas, feedback, and

      
   discussion to this document:    discussion to this document:

      
 

      
   o  Eric McMurry    o  Eric McMurry

      
 

      
   o  Hannes Tschofenig    o  Hannes Tschofenig

      
 

      
   o  Ulrich Wiehe    o  Ulrich Wiehe

      
 

      
   o  Jean-Jacques Trottin    o  Jean-Jacques Trottin

      
 

      
   o  Maria Cruz Bartolome    o  Maria Cruz Bartolome

      
 

      
   o  Martin Dolly    o  Martin Dolly

      
 

      
   o  Nirav Salot    o  Nirav Salot

      
 

      
   o  Susan Shishufeng    o  Susan Shishufeng

      
 

      

      
11.  References 12.  References

      
 

      

      
11.1.  Normative References 12.1.  Normative References

      
 

      
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

      
              Requirement Levels", BCP 14, RFC 2119, March 1997.               Requirement Levels", BCP 14, RFC 2119, March 1997.

      
 

      
   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an    [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an

      
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,               IANA Considerations Section in RFCs", BCP 26, RFC 5226,

      
              May 2008.               May 2008.

      
 

      

      
   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 

      
              Time Protocol Version 4: Protocol and Algorithms 

      
              Specification", RFC 5905, June 2010. 

      
                                                                          

      
   [RFC6733]  Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,    [RFC6733]  Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,

      
              "Diameter Base Protocol", RFC 6733, October 2012.               "Diameter Base Protocol", RFC 6733, October 2012.

      
 

      

      
11.2.  Informative References 12.2.  Informative References

      
 

      
   [Cx]       3GPP, , "ETSI TS 129 229 V11.4.0", August 2013.    [Cx]       3GPP, , "ETSI TS 129 229 V11.4.0", August 2013.

      
 

      
   [I-D.ietf-dime-e2e-sec-req]    [I-D.ietf-dime-e2e-sec-req]

      
              Tschofenig, H., Korhonen, J., Zorn, G., and K. Pillay,               Tschofenig, H., Korhonen, J., Zorn, G., and K. Pillay,

      
              "Diameter AVP Level Security: Scenarios and Requirements",               "Diameter AVP Level Security: Scenarios and Requirements",

      

      
              draft-ietf-dime-e2e-sec-req-00 (work in progress),               draft-ietf-dime-e2e-sec-req-01 (work in progress), October

      
              September 2013.               2013.

      
 

      
   [PCC]      3GPP, , "ETSI TS 123 203 V11.12.0", December 2013.    [PCC]      3GPP, , "ETSI TS 123 203 V11.12.0", December 2013.

      
 

      
   [RFC4006]  Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.    [RFC4006]  Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.

      
              Loughney, "Diameter Credit-Control Application", RFC 4006,               Loughney, "Diameter Credit-Control Application", RFC 4006,

      
              August 2005.               August 2005.

      
 

      

      
   [RFC5729]  Korhonen, J., Jones, M., Morand, L., and T. Tsou, 

      
              "Clarifications on the Routing of Diameter Requests Based 

      
              on the Username and the Realm", RFC 5729, December 2009. 

      
                                                                          

      
   [RFC7068]  McMurry, E. and B. Campbell, "Diameter Overload Control    [RFC7068]  McMurry, E. and B. Campbell, "Diameter Overload Control

      
              Requirements", RFC 7068, November 2013.               Requirements", RFC 7068, November 2013.

      
 

      
   [S13]      3GPP, , "ETSI TS 129 272 V11.9.0", December 2012.    [S13]      3GPP, , "ETSI TS 129 272 V11.9.0", December 2012.

      
 

      
Appendix A.  Issues left for future specifications Appendix A.  Issues left for future specifications

      
 

      
   The base solution for the overload control does not cover all    The base solution for the overload control does not cover all

      
   possible use cases.  A number of solution aspects were intentionally    possible use cases.  A number of solution aspects were intentionally

      
   left for future specification and protocol work.  The following sub-    left for future specification and protocol work.  The following sub-

      
   sections define some of the potential extensions to the DOIC    sections define some of the potential extensions to the DOIC

      
   solution.    solution.

      
 

      
A.1.  Additional traffic abatement algorithms A.1.  Additional traffic abatement algorithms

      
 

      
   This specification describes only means for a simple loss based    This specification describes only means for a simple loss based

      
   algorithm.  Future algorithms can be added using the designed    algorithm.  Future algorithms can be added using the designed

      
   solution extension mechanism.  The new algorithms need to be    solution extension mechanism.  The new algorithms need to be

      

      
   registered with IANA.  See Sections 6.1 and 8 for the required IANA    registered with IANA.  See Sections 7.1 and 9 for the required IANA

      
   steps.    steps.

      
 

      
A.2.  Agent Overload A.2.  Agent Overload

      
 

      
   This specification focuses on Diameter endpoint (server or client)    This specification focuses on Diameter endpoint (server or client)

      
   overload.  A separate extension will be required to outline the    overload.  A separate extension will be required to outline the

      
   handling of the case of agent overload.    handling of the case of agent overload.

      
 

      
A.3.  New Error Diagnostic AVP A.3.  New Error Diagnostic AVP

      
 


     
 

     
 End of changes. 131 change blocks. 

     
352 lines changed or deleted 295 lines changed or added

     

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ 

   

   
   
X-Generator: pyht 0.35


--------------000005080501070401070001--


From nobody Fri Dec 26 09:01:10 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8B21A004E for ; Thu, 25 Dec 2014 22:04:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.912
X-Spam-Level: 
X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwY9G10AHyfZ for ; Thu, 25 Dec 2014 22:04:45 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id DB53F1A3B9B for ; Thu, 25 Dec 2014 22:04:44 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 493B018008C; Thu, 25 Dec 2014 22:03:57 -0800 (PST)
To: vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.nospam@gmail.com, lionel.morand@orange.com
X-PHP-Originating-Script: 6000:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20141226060357.493B018008C@rfc-editor.org>
Date: Thu, 25 Dec 2014 22:03:57 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5Cg8LEZWCWx0XqV4pihbmwqY3x4
X-Mailman-Approved-At: Fri, 26 Dec 2014 09:01:09 -0800
Cc: dime@ietf.org, Hans.Liu@alcatel-lucent.com, rfc-editor@rfc-editor.org
Subject: [Dime] [Technical Errata Reported] RFC6733 (4209)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Dec 2014 06:04:47 -0000

The following errata report has been submitted for RFC6733,
"Diameter Base Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4209

--------------------------------------
Type: Technical
Reported by: Hans Liu 

Section: 5.4.3

Original Text
-------------
      BUSY                              1
         The peer’s internal resources are constrained, and it has
         determined that the transport connection needs to be closed.
         A receiver of a DPR with above result code SHOULD NOT attempt
         reconnection.

Corrected Text
--------------
      BUSY                              1
         The peer’s internal resources are constrained, and it has
         determined that the transport connection needs to be closed.
         A receiver of a DPR with above result code SHOULD either 
         connect to an alternate node, or attempt reconnection
         after a time period.

Notes
-----
In most implementations, the Diameter node will continue to serve its peer after the resources recover and expect reconnection. If the Diameter node won't like reconnection from peer, DO_NOT_WANT_TO_TALK_TO_YOU can be used instead of BUSY.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6733 (draft-ietf-dime-rfc3588bis-33)
--------------------------------------
Title               : Diameter Base Protocol
Publication Date    : October 2012
Author(s)           : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.
Category            : PROPOSED STANDARD
Source              : Diameter Maintenance and Extensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


From nobody Fri Dec 26 09:01:13 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE15C1A3B9B for ; Thu, 25 Dec 2014 22:11:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.912
X-Spam-Level: 
X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ru8hme-Fwkzd for ; Thu, 25 Dec 2014 22:11:39 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8A91A004E for ; Thu, 25 Dec 2014 22:11:39 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id C99B318008C; Thu, 25 Dec 2014 22:10:52 -0800 (PST)
To: vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.nospam@gmail.com, lionel.morand@orange.com
X-PHP-Originating-Script: 6000:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20141226061052.C99B318008C@rfc-editor.org>
Date: Thu, 25 Dec 2014 22:10:52 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/EkzOviu7x_rjBrMgVRWdeTRXBTs
X-Mailman-Approved-At: Fri, 26 Dec 2014 09:01:09 -0800
Cc: dime@ietf.org, Hans.Liu@alcatel-lucent.com, rfc-editor@rfc-editor.org
Subject: [Dime] [Editorial Errata Reported] RFC6733 (4210)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Dec 2014 06:11:41 -0000

The following errata report has been submitted for RFC6733,
"Diameter Base Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4210

--------------------------------------
Type: Editorial
Reported by: Hans Liu 

Section: 5.4.3

Original Text
-------------
   The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated.  A
   Diameter node MUST include this AVP in the Disconnect-Peer-Request
   message to inform the peer of the reason for its intention to shut
   down the transport connection.  The following values are supported:
      REBOOTING                         0
         A scheduled reboot is imminent.  A receiver of a DPR with
         above result code MAY attempt reconnection.
      BUSY                              1
         The peer’s internal resources are constrained, and it has
         determined that the transport connection needs to be closed.
         A receiver of a DPR with above result code SHOULD NOT attempt
         reconnection.
      DO_NOT_WANT_TO_TALK_TO_YOU        2
         The peer has determined that it does not see a need for the
         transport connection to exist, since it does not expect any
         messages to be exchanged in the near future.  A receiver of a
         DPR with above result code SHOULD NOT attempt reconnection.

Corrected Text
--------------
   The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated.  A
   Diameter node MUST include this AVP in the Disconnect-Peer-Request
   message to inform the peer of the reason for its intention to shut
   down the transport connection.  The following values are supported:
      REBOOTING                         0
         A scheduled reboot is imminent.  A receiver of a DPR with
         above result code MAY attempt reconnection.
      BUSY                              1
         The internal resources are constrained, and it has
         determined that the transport connection needs to be closed.
         A receiver of a DPR with above result code SHOULD NOT attempt
         reconnection.
      DO_NOT_WANT_TO_TALK_TO_YOU        2
         The node has determined that it does not see a need for the
         transport connection to exist, since it does not expect any
         messages to be exchanged in the near future.  A receiver of a
         DPR with above result code SHOULD NOT attempt reconnection.

Notes
-----
The "peer" in 1st paragraph represents the receiver. However in the descriptions for cause values the "peer" represents the sender.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6733 (draft-ietf-dime-rfc3588bis-33)
--------------------------------------
Title               : Diameter Base Protocol
Publication Date    : October 2012
Author(s)           : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.
Category            : PROPOSED STANDARD
Source              : Diameter Maintenance and Extensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


From nobody Fri Dec 26 10:28:21 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0621A9102 for ; Fri, 26 Dec 2014 09:34:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHODGYB8t-fq for ; Fri, 26 Dec 2014 09:34:55 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B1CA1A9100 for ; Fri, 26 Dec 2014 09:34:54 -0800 (PST)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 60954374355; Fri, 26 Dec 2014 18:34:52 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 3313F158098; Fri, 26 Dec 2014 18:34:52 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Fri, 26 Dec 2014 18:34:51 +0100
From: 
To: RFC Errata System , "vf0213@gmail.com" , "jari.arkko@ericsson.com" , "john.loughney@nokia.com" , "glenzorn@gmail.com" , "bclaise@cisco.com" , "joelja@bogus.com" , "jouni.nospam@gmail.com" 
Thread-Topic: [Editorial Errata Reported] RFC6733 (4210)
Thread-Index: AQHQINLSBW5CLwQOE0muYZ1BflrdvJyiIc9g
Date: Fri, 26 Dec 2014 17:34:51 +0000
Message-ID: <19574_1419615292_549D9C3C_19574_2784_1_6B7134B31289DC4FAF731D844122B36EA6E945@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <20141226061052.C99B318008C@rfc-editor.org>
In-Reply-To: <20141226061052.C99B318008C@rfc-editor.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.2]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.22.200030
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/wSg14IKS3A9pbNTYx7XdftRxszU
X-Mailman-Approved-At: Fri, 26 Dec 2014 10:28:21 -0800
Cc: "dime@ietf.org" , "Hans.Liu@alcatel-lucent.com" 
Subject: Re: [Dime] [Editorial Errata Reported] RFC6733 (4210)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Dec 2014 17:34:58 -0000

RGlhbWV0ZXIgaXMgYSBwZWVyLXRvLXBlZXIgcHJvdG9jb2wgYW5kIHBlZXJzIGFyZSBEaWFtZXRl
ciBub2RlcyBzaGFyaW5nIGEgRGlhbWV0ZXIgdHJhbnNwb3J0IGNvbm5lY3Rpb24uIFRoZXJlZm9y
ZSwgYSAicGVlciIgY2FuIGJlIGVpdGhlciB0aGUgc2VuZGVyIG9yIHRoZSByZWNlaXZlciBvZiB0
aGUgcmVxdWVzdCwgZGVwZW5kaW5nIG9uIHRoZSBjb250ZXh0Lg0KSSBkb24ndCB0aGluayB0aGF0
IHRoZSBwcm9wb3NlZCBjb3JyZWN0aW9uIGlzIGp1c3RpZmllZC4NCg0KcmVnYXJkcywNCg0KTGlv
bmVsDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogUkZDIEVycmF0YSBTeXN0
ZW0gW21haWx0bzpyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnXSANCkVudm95w6nCoDogdmVuZHJl
ZGkgMjYgZMOpY2VtYnJlIDIwMTQgMDc6MTENCsOAwqA6IHZmMDIxM0BnbWFpbC5jb207IGphcmku
YXJra29AZXJpY3Nzb24uY29tOyBqb2huLmxvdWdobmV5QG5va2lhLmNvbTsgZ2xlbnpvcm5AZ21h
aWwuY29tOyBiY2xhaXNlQGNpc2NvLmNvbTsgam9lbGphQGJvZ3VzLmNvbTsgam91bmkubm9zcGFt
QGdtYWlsLmNvbTsgTU9SQU5EIExpb25lbCBJTVQvT0xODQpDY8KgOiBIYW5zLkxpdUBhbGNhdGVs
LWx1Y2VudC5jb207IGRpbWVAaWV0Zi5vcmc7IHJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmcNCk9i
amV0wqA6IFtFZGl0b3JpYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2NzMzICg0MjEwKQ0KDQpUaGUg
Zm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVkIGZvciBSRkM2NzMzLCAi
RGlhbWV0ZXIgQmFzZSBQcm90b2NvbCIuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQpZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFuZCBhdDoNCmh0dHA6
Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTY3MzMmZWlkPTQyMTAN
Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClR5cGU6IEVkaXRvcmlh
bA0KUmVwb3J0ZWQgYnk6IEhhbnMgTGl1IDxIYW5zLkxpdUBhbGNhdGVsLWx1Y2VudC5jb20+DQoN
ClNlY3Rpb246IDUuNC4zDQoNCk9yaWdpbmFsIFRleHQNCi0tLS0tLS0tLS0tLS0NCiAgIFRoZSBE
aXNjb25uZWN0LUNhdXNlIEFWUCAoQVZQIENvZGUgMjczKSBpcyBvZiB0eXBlIEVudW1lcmF0ZWQu
ICBBDQogICBEaWFtZXRlciBub2RlIE1VU1QgaW5jbHVkZSB0aGlzIEFWUCBpbiB0aGUgRGlzY29u
bmVjdC1QZWVyLVJlcXVlc3QNCiAgIG1lc3NhZ2UgdG8gaW5mb3JtIHRoZSBwZWVyIG9mIHRoZSBy
ZWFzb24gZm9yIGl0cyBpbnRlbnRpb24gdG8gc2h1dA0KICAgZG93biB0aGUgdHJhbnNwb3J0IGNv
bm5lY3Rpb24uICBUaGUgZm9sbG93aW5nIHZhbHVlcyBhcmUgc3VwcG9ydGVkOg0KICAgICAgUkVC
T09USU5HICAgICAgICAgICAgICAgICAgICAgICAgIDANCiAgICAgICAgIEEgc2NoZWR1bGVkIHJl
Ym9vdCBpcyBpbW1pbmVudC4gIEEgcmVjZWl2ZXIgb2YgYSBEUFIgd2l0aA0KICAgICAgICAgYWJv
dmUgcmVzdWx0IGNvZGUgTUFZIGF0dGVtcHQgcmVjb25uZWN0aW9uLg0KICAgICAgQlVTWSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDENCiAgICAgICAgIFRoZSBwZWVyw6LigqzihKJzIGlu
dGVybmFsIHJlc291cmNlcyBhcmUgY29uc3RyYWluZWQsIGFuZCBpdCBoYXMNCiAgICAgICAgIGRl
dGVybWluZWQgdGhhdCB0aGUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gbmVlZHMgdG8gYmUgY2xvc2Vk
Lg0KICAgICAgICAgQSByZWNlaXZlciBvZiBhIERQUiB3aXRoIGFib3ZlIHJlc3VsdCBjb2RlIFNI
T1VMRCBOT1QgYXR0ZW1wdA0KICAgICAgICAgcmVjb25uZWN0aW9uLg0KICAgICAgRE9fTk9UX1dB
TlRfVE9fVEFMS19UT19ZT1UgICAgICAgIDINCiAgICAgICAgIFRoZSBwZWVyIGhhcyBkZXRlcm1p
bmVkIHRoYXQgaXQgZG9lcyBub3Qgc2VlIGEgbmVlZCBmb3IgdGhlDQogICAgICAgICB0cmFuc3Bv
cnQgY29ubmVjdGlvbiB0byBleGlzdCwgc2luY2UgaXQgZG9lcyBub3QgZXhwZWN0IGFueQ0KICAg
ICAgICAgbWVzc2FnZXMgdG8gYmUgZXhjaGFuZ2VkIGluIHRoZSBuZWFyIGZ1dHVyZS4gIEEgcmVj
ZWl2ZXIgb2YgYQ0KICAgICAgICAgRFBSIHdpdGggYWJvdmUgcmVzdWx0IGNvZGUgU0hPVUxEIE5P
VCBhdHRlbXB0IHJlY29ubmVjdGlvbi4NCg0KQ29ycmVjdGVkIFRleHQNCi0tLS0tLS0tLS0tLS0t
DQogICBUaGUgRGlzY29ubmVjdC1DYXVzZSBBVlAgKEFWUCBDb2RlIDI3MykgaXMgb2YgdHlwZSBF
bnVtZXJhdGVkLiAgQQ0KICAgRGlhbWV0ZXIgbm9kZSBNVVNUIGluY2x1ZGUgdGhpcyBBVlAgaW4g
dGhlIERpc2Nvbm5lY3QtUGVlci1SZXF1ZXN0DQogICBtZXNzYWdlIHRvIGluZm9ybSB0aGUgcGVl
ciBvZiB0aGUgcmVhc29uIGZvciBpdHMgaW50ZW50aW9uIHRvIHNodXQNCiAgIGRvd24gdGhlIHRy
YW5zcG9ydCBjb25uZWN0aW9uLiAgVGhlIGZvbGxvd2luZyB2YWx1ZXMgYXJlIHN1cHBvcnRlZDoN
CiAgICAgIFJFQk9PVElORyAgICAgICAgICAgICAgICAgICAgICAgICAwDQogICAgICAgICBBIHNj
aGVkdWxlZCByZWJvb3QgaXMgaW1taW5lbnQuICBBIHJlY2VpdmVyIG9mIGEgRFBSIHdpdGgNCiAg
ICAgICAgIGFib3ZlIHJlc3VsdCBjb2RlIE1BWSBhdHRlbXB0IHJlY29ubmVjdGlvbi4NCiAgICAg
IEJVU1kgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxDQogICAgICAgICBUaGUgaW50ZXJu
YWwgcmVzb3VyY2VzIGFyZSBjb25zdHJhaW5lZCwgYW5kIGl0IGhhcw0KICAgICAgICAgZGV0ZXJt
aW5lZCB0aGF0IHRoZSB0cmFuc3BvcnQgY29ubmVjdGlvbiBuZWVkcyB0byBiZSBjbG9zZWQuDQog
ICAgICAgICBBIHJlY2VpdmVyIG9mIGEgRFBSIHdpdGggYWJvdmUgcmVzdWx0IGNvZGUgU0hPVUxE
IE5PVCBhdHRlbXB0DQogICAgICAgICByZWNvbm5lY3Rpb24uDQogICAgICBET19OT1RfV0FOVF9U
T19UQUxLX1RPX1lPVSAgICAgICAgMg0KICAgICAgICAgVGhlIG5vZGUgaGFzIGRldGVybWluZWQg
dGhhdCBpdCBkb2VzIG5vdCBzZWUgYSBuZWVkIGZvciB0aGUNCiAgICAgICAgIHRyYW5zcG9ydCBj
b25uZWN0aW9uIHRvIGV4aXN0LCBzaW5jZSBpdCBkb2VzIG5vdCBleHBlY3QgYW55DQogICAgICAg
ICBtZXNzYWdlcyB0byBiZSBleGNoYW5nZWQgaW4gdGhlIG5lYXIgZnV0dXJlLiAgQSByZWNlaXZl
ciBvZiBhDQogICAgICAgICBEUFIgd2l0aCBhYm92ZSByZXN1bHQgY29kZSBTSE9VTEQgTk9UIGF0
dGVtcHQgcmVjb25uZWN0aW9uLg0KDQpOb3Rlcw0KLS0tLS0NClRoZSAicGVlciIgaW4gMXN0IHBh
cmFncmFwaCByZXByZXNlbnRzIHRoZSByZWNlaXZlci4gSG93ZXZlciBpbiB0aGUgZGVzY3JpcHRp
b25zIGZvciBjYXVzZSB2YWx1ZXMgdGhlICJwZWVyIiByZXByZXNlbnRzIHRoZSBzZW5kZXIuDQoN
Ckluc3RydWN0aW9uczoNCi0tLS0tLS0tLS0tLS0NClRoaXMgZXJyYXR1bSBpcyBjdXJyZW50bHkg
cG9zdGVkIGFzICJSZXBvcnRlZCIuIElmIG5lY2Vzc2FyeSwgcGxlYXNlIHVzZSAiUmVwbHkgQWxs
IiB0byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hvdWxkIGJlIHZlcmlmaWVkIG9yIHJlamVjdGVkLiBX
aGVuIGEgZGVjaXNpb24gaXMgcmVhY2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0eSAoSUVTRykgY2Fu
IGxvZyBpbiB0byBjaGFuZ2UgdGhlIHN0YXR1cyBhbmQgZWRpdCB0aGUgcmVwb3J0LCBpZiBuZWNl
c3NhcnkuIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KUkZDNjcz
MyAoZHJhZnQtaWV0Zi1kaW1lLXJmYzM1ODhiaXMtMzMpDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQ0KVGl0bGUgICAgICAgICAgICAgICA6IERpYW1ldGVyIEJhc2UgUHJv
dG9jb2wNClB1YmxpY2F0aW9uIERhdGUgICAgOiBPY3RvYmVyIDIwMTINCkF1dGhvcihzKSAgICAg
ICAgICAgOiBWLiBGYWphcmRvLCBFZC4sIEouIEFya2tvLCBKLiBMb3VnaG5leSwgRy4gWm9ybiwg
RWQuDQpDYXRlZ29yeSAgICAgICAgICAgIDogUFJPUE9TRUQgU1RBTkRBUkQNClNvdXJjZSAgICAg
ICAgICAgICAgOiBEaWFtZXRlciBNYWludGVuYW5jZSBhbmQgRXh0ZW5zaW9ucw0KQXJlYSAgICAg
ICAgICAgICAgICA6IE9wZXJhdGlvbnMgYW5kIE1hbmFnZW1lbnQNClN0cmVhbSAgICAgICAgICAg
ICAgOiBJRVRGDQpWZXJpZnlpbmcgUGFydHkgICAgIDogSUVTRw0KDQoKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVz
c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp
b25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBh
cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT
aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h
bGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpv
aW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2Fs
dGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh
Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2Fn
ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl
Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxk
IG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9u
LgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5
IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4K
QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn
ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5
b3UuCgo=


From Hans.Liu@alcatel-lucent.com  Sun Dec 28 05:29:51 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761531AD43C for ; Sun, 28 Dec 2014 05:29:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50MvnqN095mR for ; Sun, 28 Dec 2014 05:29:45 -0800 (PST)
Received: from cnshjsmin04.alcatel-sbell.com.cn (cnshjsmin03.alcatel-sbell.com.cn [211.144.215.47]) by ietfa.amsl.com (Postfix) with ESMTP id E8AFE1AD43D for ; Sun, 28 Dec 2014 05:29:43 -0800 (PST)
X-AuditID: ac189298-f79b46d000003ac1-49-54a005c5d8e7
Received: from CNSHJCASHUB02.ad4.ad.alcatel.com (CNSHJCASHUB02.ad4.ad.alcatel.com [135.251.50.72]) by cnshjsmin04.alcatel-sbell.com.cn (Symantec Messaging Gateway) with SMTP id E0.0E.15041.5C500A45; Sun, 28 Dec 2014 21:29:41 +0800 (HKT)
Received: from CNSHJMBX01.ad4.ad.alcatel.com ([135.251.50.101]) by CNSHJCASHUB02.ad4.ad.alcatel.com ([135.251.50.72]) with mapi id 14.03.0123.003; Sun, 28 Dec 2014 21:29:39 +0800
From: LIU Hans 
To: "lionel.morand@orange.com" , RFC Errata System , "vf0213@gmail.com" , "jari.arkko@ericsson.com" , "john.loughney@nokia.com" , "glenzorn@gmail.com" , "bclaise@cisco.com" , "joelja@bogus.com" , "jouni.nospam@gmail.com" 
Thread-Topic: [Editorial Errata Reported] RFC6733 (4210)
Thread-Index: AQHQINLSBW5CLwQOE0muYZ1BflrdvJyiIc9ggALdfUA=
Date: Sun, 28 Dec 2014 13:29:38 +0000
Message-ID: 
References: <20141226061052.C99B318008C@rfc-editor.org> <19574_1419615292_549D9C3C_19574_2784_1_6B7134B31289DC4FAF731D844122B36EA6E945@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <19574_1419615292_549D9C3C_19574_2784_1_6B7134B31289DC4FAF731D844122B36EA6E945@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.24.110.144]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCIsWRmVeSWpSXmKPExsXS/ts0Uvco64IQgzm7FC2OPpawmNu7gs1i /eRLLBaHevIsXp1aw2hx7OZKJov96xqYLG5vz7Ro2v+VzeJZSz+7A5fH2SMLGD2m/N7I6vHr 61U2j52z7rJ7LFnyk8nj7q1LTB4tz06yeTS0HWMN4IjisklJzcksSy3St0vgytg4cylrwRr7 ijPXlrM2MN6x7WLk5JAQMJGYtHgOM4QtJnHh3nq2LkYuDiGBd4wSky70MEM42xgl1q1YzAZS xSagI/FiWjc7SEJEYDOzRN/dL6wgCWYBZYnZOx6wg9jCAuYSnZ82MoHYIgIWEg/3djJD2FYS 168dA7NZBFQl5h7cBVbPK+AosePZM1aIbZsZJQ5NXcsE4nAKtDFKTJz/C6yKUUBWYtqj+0wQ 28Qlbj2ZzwRxuIDEkj3noZ4QlXj5+B8rhK0k8WL9XaAaDqB6TYn1u/QhWhUlpnQ/hFosKHFy 5hMWiHJJiYMrbrBMYBSfhWTDLITuWUi6ZyHpXsDIsopRITmvOCOrODczz8BILzEnObEkNUe3 OCk1J0cvOT9XLzlvEyMw7tdITJqxg/HsU6dDjAIcjEo8vC9OzA8RYk0sK67MPcQowcGsJMIb 8QQoxJuSWFmVWpQfX1Sak1p8iFGag0VJnDf9TX+IkEA60Ozs1NSC1CKYLBMHp1QDY63u1x+i Tn9uMzX2rSsK6Dox+2mtSs75v1uqpzk7SqrU6vtslnI5UcbaU8bl/Za5xy+Cz2/CUXnL3fay Qp8myO+9Huv/7cePjee4P6nZp5memjFbOMrKOamiw7B32VYT9SXfXsz91MO79//lnW6+/131 j8/ca2rGFL35sdWRV3elOSeFhq+rUmIpzkg01GIuKk4EAHI19j/3AgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/hAy89FmMdvL9t5p2UbZLmKpMPc4
X-Mailman-Approved-At: Sun, 28 Dec 2014 18:20:15 -0800
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [Editorial Errata Reported] RFC6733 (4210)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Dec 2014 13:34:40 -0000

SGkgTGlvbmVsLA0KDQpUaGFua3MgZm9yIHlvdXIgcXVpY2sgcmVzcG9uc2UuIA0KDQpJIGFncmVl
IHdpdGggeW91IHRoYXQgYSBwZWVyIGNhbiBlaXRoZXIgYmUgYSBzZW5kZXIgb3IgcmVjZWl2ZXIu
IA0KDQpIb3dldmVyIGluIHNhbWUgc2VjdGlvbiBkZXNjcmliaW5nIHVzYWdlIGZvciB0aGUgc2Ft
ZSBBVlAsIHRoZSAxc3QgYXBwZWFyYW5jZSByZXByZXNlbnRzIHRoZSByb2xlIG9mIHJlY2VpdmVy
LCB0aGUgMm5kIGFuZCAzcmQgYXBwZWFyYW5jZXMgaGFzIGNoYW5nZWQgdG8gdGhlIHJvbGUgb2Yg
c2VuZGVycywgaXQncyBjb25mdXNpbmcgbGl0ZXJhbGx5Lg0KDQpUaGFua3MsDQpIYW5zDQoNCi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20g
W21haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb21dIA0KU2VudDogMjAxNOW5tDEy5pyIMjfm
l6UgMTozNQ0KVG86IFJGQyBFcnJhdGEgU3lzdGVtOyB2ZjAyMTNAZ21haWwuY29tOyBqYXJpLmFy
a2tvQGVyaWNzc29uLmNvbTsgam9obi5sb3VnaG5leUBub2tpYS5jb207IGdsZW56b3JuQGdtYWls
LmNvbTsgYmNsYWlzZUBjaXNjby5jb207IGpvZWxqYUBib2d1cy5jb207IGpvdW5pLm5vc3BhbUBn
bWFpbC5jb20NCkNjOiBMSVUgSGFuczsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtFZGl0
b3JpYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2NzMzICg0MjEwKQ0KDQpEaWFtZXRlciBpcyBhIHBl
ZXItdG8tcGVlciBwcm90b2NvbCBhbmQgcGVlcnMgYXJlIERpYW1ldGVyIG5vZGVzIHNoYXJpbmcg
YSBEaWFtZXRlciB0cmFuc3BvcnQgY29ubmVjdGlvbi4gVGhlcmVmb3JlLCBhICJwZWVyIiBjYW4g
YmUgZWl0aGVyIHRoZSBzZW5kZXIgb3IgdGhlIHJlY2VpdmVyIG9mIHRoZSByZXF1ZXN0LCBkZXBl
bmRpbmcgb24gdGhlIGNvbnRleHQuDQpJIGRvbid0IHRoaW5rIHRoYXQgdGhlIHByb3Bvc2VkIGNv
cnJlY3Rpb24gaXMganVzdGlmaWVkLg0KDQpyZWdhcmRzLA0KDQpMaW9uZWwNCg0KLS0tLS1NZXNz
YWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBSRkMgRXJyYXRhIFN5c3RlbSBbbWFpbHRvOnJmYy1l
ZGl0b3JAcmZjLWVkaXRvci5vcmddDQpFbnZvecOpwqA6IHZlbmRyZWRpIDI2IGTDqWNlbWJyZSAy
MDE0IDA3OjExIMOAwqA6IHZmMDIxM0BnbWFpbC5jb207IGphcmkuYXJra29AZXJpY3Nzb24uY29t
OyBqb2huLmxvdWdobmV5QG5va2lhLmNvbTsgZ2xlbnpvcm5AZ21haWwuY29tOyBiY2xhaXNlQGNp
c2NvLmNvbTsgam9lbGphQGJvZ3VzLmNvbTsgam91bmkubm9zcGFtQGdtYWlsLmNvbTsgTU9SQU5E
IExpb25lbCBJTVQvT0xOIENjwqA6IEhhbnMuTGl1QGFsY2F0ZWwtbHVjZW50LmNvbTsgZGltZUBp
ZXRmLm9yZzsgcmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZyBPYmpldMKgOiBbRWRpdG9yaWFsIEVy
cmF0YSBSZXBvcnRlZF0gUkZDNjczMyAoNDIxMCkNCg0KVGhlIGZvbGxvd2luZyBlcnJhdGEgcmVw
b3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgUkZDNjczMywgIkRpYW1ldGVyIEJhc2UgUHJvdG9j
b2wiLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWW91IG1heSBy
ZXZpZXcgdGhlIHJlcG9ydCBiZWxvdyBhbmQgYXQ6DQpodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3Jn
L2VycmF0YV9zZWFyY2gucGhwP3JmYz02NzMzJmVpZD00MjEwDQoNCi0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUeXBlOiBFZGl0b3JpYWwNClJlcG9ydGVkIGJ5OiBIYW5z
IExpdSA8SGFucy5MaXVAYWxjYXRlbC1sdWNlbnQuY29tPg0KDQpTZWN0aW9uOiA1LjQuMw0KDQpP
cmlnaW5hbCBUZXh0DQotLS0tLS0tLS0tLS0tDQogICBUaGUgRGlzY29ubmVjdC1DYXVzZSBBVlAg
KEFWUCBDb2RlIDI3MykgaXMgb2YgdHlwZSBFbnVtZXJhdGVkLiAgQQ0KICAgRGlhbWV0ZXIgbm9k
ZSBNVVNUIGluY2x1ZGUgdGhpcyBBVlAgaW4gdGhlIERpc2Nvbm5lY3QtUGVlci1SZXF1ZXN0DQog
ICBtZXNzYWdlIHRvIGluZm9ybSB0aGUgcGVlciBvZiB0aGUgcmVhc29uIGZvciBpdHMgaW50ZW50
aW9uIHRvIHNodXQNCiAgIGRvd24gdGhlIHRyYW5zcG9ydCBjb25uZWN0aW9uLiAgVGhlIGZvbGxv
d2luZyB2YWx1ZXMgYXJlIHN1cHBvcnRlZDoNCiAgICAgIFJFQk9PVElORyAgICAgICAgICAgICAg
ICAgICAgICAgICAwDQogICAgICAgICBBIHNjaGVkdWxlZCByZWJvb3QgaXMgaW1taW5lbnQuICBB
IHJlY2VpdmVyIG9mIGEgRFBSIHdpdGgNCiAgICAgICAgIGFib3ZlIHJlc3VsdCBjb2RlIE1BWSBh
dHRlbXB0IHJlY29ubmVjdGlvbi4NCiAgICAgIEJVU1kgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAxDQogICAgICAgICBUaGUgcGVlcsOi4oKs4oSicyBpbnRlcm5hbCByZXNvdXJjZXMgYXJl
IGNvbnN0cmFpbmVkLCBhbmQgaXQgaGFzDQogICAgICAgICBkZXRlcm1pbmVkIHRoYXQgdGhlIHRy
YW5zcG9ydCBjb25uZWN0aW9uIG5lZWRzIHRvIGJlIGNsb3NlZC4NCiAgICAgICAgIEEgcmVjZWl2
ZXIgb2YgYSBEUFIgd2l0aCBhYm92ZSByZXN1bHQgY29kZSBTSE9VTEQgTk9UIGF0dGVtcHQNCiAg
ICAgICAgIHJlY29ubmVjdGlvbi4NCiAgICAgIERPX05PVF9XQU5UX1RPX1RBTEtfVE9fWU9VICAg
ICAgICAyDQogICAgICAgICBUaGUgcGVlciBoYXMgZGV0ZXJtaW5lZCB0aGF0IGl0IGRvZXMgbm90
IHNlZSBhIG5lZWQgZm9yIHRoZQ0KICAgICAgICAgdHJhbnNwb3J0IGNvbm5lY3Rpb24gdG8gZXhp
c3QsIHNpbmNlIGl0IGRvZXMgbm90IGV4cGVjdCBhbnkNCiAgICAgICAgIG1lc3NhZ2VzIHRvIGJl
IGV4Y2hhbmdlZCBpbiB0aGUgbmVhciBmdXR1cmUuICBBIHJlY2VpdmVyIG9mIGENCiAgICAgICAg
IERQUiB3aXRoIGFib3ZlIHJlc3VsdCBjb2RlIFNIT1VMRCBOT1QgYXR0ZW1wdCByZWNvbm5lY3Rp
b24uDQoNCkNvcnJlY3RlZCBUZXh0DQotLS0tLS0tLS0tLS0tLQ0KICAgVGhlIERpc2Nvbm5lY3Qt
Q2F1c2UgQVZQIChBVlAgQ29kZSAyNzMpIGlzIG9mIHR5cGUgRW51bWVyYXRlZC4gIEENCiAgIERp
YW1ldGVyIG5vZGUgTVVTVCBpbmNsdWRlIHRoaXMgQVZQIGluIHRoZSBEaXNjb25uZWN0LVBlZXIt
UmVxdWVzdA0KICAgbWVzc2FnZSB0byBpbmZvcm0gdGhlIHBlZXIgb2YgdGhlIHJlYXNvbiBmb3Ig
aXRzIGludGVudGlvbiB0byBzaHV0DQogICBkb3duIHRoZSB0cmFuc3BvcnQgY29ubmVjdGlvbi4g
IFRoZSBmb2xsb3dpbmcgdmFsdWVzIGFyZSBzdXBwb3J0ZWQ6DQogICAgICBSRUJPT1RJTkcgICAg
ICAgICAgICAgICAgICAgICAgICAgMA0KICAgICAgICAgQSBzY2hlZHVsZWQgcmVib290IGlzIGlt
bWluZW50LiAgQSByZWNlaXZlciBvZiBhIERQUiB3aXRoDQogICAgICAgICBhYm92ZSByZXN1bHQg
Y29kZSBNQVkgYXR0ZW1wdCByZWNvbm5lY3Rpb24uDQogICAgICBCVVNZICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgMQ0KICAgICAgICAgVGhlIGludGVybmFsIHJlc291cmNlcyBhcmUgY29u
c3RyYWluZWQsIGFuZCBpdCBoYXMNCiAgICAgICAgIGRldGVybWluZWQgdGhhdCB0aGUgdHJhbnNw
b3J0IGNvbm5lY3Rpb24gbmVlZHMgdG8gYmUgY2xvc2VkLg0KICAgICAgICAgQSByZWNlaXZlciBv
ZiBhIERQUiB3aXRoIGFib3ZlIHJlc3VsdCBjb2RlIFNIT1VMRCBOT1QgYXR0ZW1wdA0KICAgICAg
ICAgcmVjb25uZWN0aW9uLg0KICAgICAgRE9fTk9UX1dBTlRfVE9fVEFMS19UT19ZT1UgICAgICAg
IDINCiAgICAgICAgIFRoZSBub2RlIGhhcyBkZXRlcm1pbmVkIHRoYXQgaXQgZG9lcyBub3Qgc2Vl
IGEgbmVlZCBmb3IgdGhlDQogICAgICAgICB0cmFuc3BvcnQgY29ubmVjdGlvbiB0byBleGlzdCwg
c2luY2UgaXQgZG9lcyBub3QgZXhwZWN0IGFueQ0KICAgICAgICAgbWVzc2FnZXMgdG8gYmUgZXhj
aGFuZ2VkIGluIHRoZSBuZWFyIGZ1dHVyZS4gIEEgcmVjZWl2ZXIgb2YgYQ0KICAgICAgICAgRFBS
IHdpdGggYWJvdmUgcmVzdWx0IGNvZGUgU0hPVUxEIE5PVCBhdHRlbXB0IHJlY29ubmVjdGlvbi4N
Cg0KTm90ZXMNCi0tLS0tDQpUaGUgInBlZXIiIGluIDFzdCBwYXJhZ3JhcGggcmVwcmVzZW50cyB0
aGUgcmVjZWl2ZXIuIEhvd2V2ZXIgaW4gdGhlIGRlc2NyaXB0aW9ucyBmb3IgY2F1c2UgdmFsdWVz
IHRoZSAicGVlciIgcmVwcmVzZW50cyB0aGUgc2VuZGVyLg0KDQpJbnN0cnVjdGlvbnM6DQotLS0t
LS0tLS0tLS0tDQpUaGlzIGVycmF0dW0gaXMgY3VycmVudGx5IHBvc3RlZCBhcyAiUmVwb3J0ZWQi
LiBJZiBuZWNlc3NhcnksIHBsZWFzZSB1c2UgIlJlcGx5IEFsbCIgdG8gZGlzY3VzcyB3aGV0aGVy
IGl0IHNob3VsZCBiZSB2ZXJpZmllZCBvciByZWplY3RlZC4gV2hlbiBhIGRlY2lzaW9uIGlzIHJl
YWNoZWQsIHRoZSB2ZXJpZnlpbmcgcGFydHkgKElFU0cpIGNhbiBsb2cgaW4gdG8gY2hhbmdlIHRo
ZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCwgaWYgbmVjZXNzYXJ5LiANCg0KLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClJGQzY3MzMgKGRyYWZ0LWlldGYtZGltZS1y
ZmMzNTg4YmlzLTMzKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRp
dGxlICAgICAgICAgICAgICAgOiBEaWFtZXRlciBCYXNlIFByb3RvY29sDQpQdWJsaWNhdGlvbiBE
YXRlICAgIDogT2N0b2JlciAyMDEyDQpBdXRob3IocykgICAgICAgICAgIDogVi4gRmFqYXJkbywg
RWQuLCBKLiBBcmtrbywgSi4gTG91Z2huZXksIEcuIFpvcm4sIEVkLg0KQ2F0ZWdvcnkgICAgICAg
ICAgICA6IFBST1BPU0VEIFNUQU5EQVJEDQpTb3VyY2UgICAgICAgICAgICAgIDogRGlhbWV0ZXIg
TWFpbnRlbmFuY2UgYW5kIEV4dGVuc2lvbnMNCkFyZWEgICAgICAgICAgICAgICAgOiBPcGVyYXRp
b25zIGFuZCBNYW5hZ2VtZW50DQpTdHJlYW0gICAgICAgICAgICAgIDogSUVURg0KVmVyaWZ5aW5n
IFBhcnR5ICAgICA6IElFU0cNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl
cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxs
ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywg
ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3Ug
Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1
ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn
ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2Ug
ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg
ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj
aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9u
IHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli
dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUg
cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu
ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5
IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg
YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCg==


From nobody Mon Dec 29 08:33:41 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256561A8953 for ; Mon, 29 Dec 2014 08:33:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.778
X-Spam-Level: 
X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0WzMNMpEi3N for ; Mon, 29 Dec 2014 08:33:38 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D980A1A894C for ; Mon, 29 Dec 2014 08:33:38 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54275 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y5dG8-0001wS-Tg; Mon, 29 Dec 2014 08:33:36 -0800
Message-ID: <54A1825B.1000503@usdonovans.com>
Date: Mon, 29 Dec 2014 10:33:31 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Ben Campbell , "DOLLY, MARTIN C" 
References: <54984D7E.3010405@usdonovans.com>    <26D1E2EC-3DF6-487C-980F-F6DBE6EFDF39@nostrum.com>
In-Reply-To: <26D1E2EC-3DF6-487C-980F-F6DBE6EFDF39@nostrum.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ERzlpdkjaHSXcAUJFEZ05t-4I7o
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Handling of mandatory sub-avps
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Dec 2014 16:33:40 -0000

Ben,

As you suggesting that just the AVP that isn't understood is ignored or 
the entire grouped AVP it is part of is ignored?  If the "sub-avp" is 
marked as mandatory then it would seem that the entire grouped AVP 
should be ignored.

Steve

On 12/22/14 10:34 PM, Ben Campbell wrote:
> Martin, I think we are violently agreeing. A DOIC "failure" doesn't impact the Diameter transaction.
>
>
>> On Dec 22, 2014, at 8:42 PM, DOLLY, MARTIN C  wrote:
>>
>> To be clear, ignore what one does not understand.
>>
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C
>> Sent: Monday, December 22, 2014 9:34 PM
>> To: Ben Campbell; Steve Donovan
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] Handling of mandatory sub-avps
>>
>> *** Security Advisory: This Message Originated Outside of AT&T ***.
>> Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
>>
>> NO, WRONG
>>
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
>> Sent: Monday, December 22, 2014 7:16 PM
>> To: Steve Donovan
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] Handling of mandatory sub-avps
>>
>> My opinion is that any DOIC error (i.e. something wrong in OC-S-F or OC-OLR) should never cause an error or other failure of the enclosing transaction. Normally the only way DOIC should affect a transaction is via abatement.
>>
>> I would grudgingly accept the ability for a Diameter application spec to say that the application must not be used without DOIC (and potentially certain DOIC features.), as long as such a requirement was explicit (including explicit on _how_ it should fail), but I think that's a different use case.
>>
>>> On Dec 22, 2014, at 10:57 AM, Steve Donovan  wrote:
>>>
>>> All,
>>>
>>> The following is an open issue from Ben's suggested editorial changes that still needs to be addressed.
>>>
>>> Regards,
>>>
>>> Steve
>>>>> -- 4.3, para 4:
>>>>>
>>>>> We should clarify that this is talking about mandatory to understand for DOIC, but not for the enclosing transaction.
>>>> SRD> i'm not clear on what you are suggesting.
>>> We need to be clear that receiving a DOIC avp with a mandatory AVP that you don't understand means you ignore the DOIC AVPs, but does not cause the Diameter transaction to fail. Or was it your intent to allow an application to say that if you get a DOIC avp that you can't process, you have to fail the Diameter transaction?
>>>
>>>> Do you have suggested wording?
>>> Depends on the answer to the question above.
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime


From nobody Mon Dec 29 08:38:57 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BA11A8953 for ; Mon, 29 Dec 2014 08:38:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.778
X-Spam-Level: 
X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzKNze3jzWbM for ; Mon, 29 Dec 2014 08:38:54 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42601A8949 for ; Mon, 29 Dec 2014 08:38:54 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54284 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y5dLI-00098f-44; Mon, 29 Dec 2014 08:38:53 -0800
Message-ID: <54A1839B.1050009@usdonovans.com>
Date: Mon, 29 Dec 2014 10:38:51 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Ben Campbell 
References: <79E0AA6A-8F91-45FD-AE8A-EFF9D2A4E9D3@nostrum.com> <5491AEC7.8070307@usdonovans.com>  <54984D31.5000201@usdonovans.com> <00328701-E938-444C-B8BC-ADBE05B201CB@nostrum.com>
In-Reply-To: <00328701-E938-444C-B8BC-ADBE05B201CB@nostrum.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2pIooooEFXVHEasD6rEIiwcZwt0
Cc: dime@ietf.org
Subject: Re: [Dime] DOIC WGLC: Editorial Comments
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Dec 2014 16:38:55 -0000

On 12/22/14 6:11 PM, Ben Campbell wrote:
> Hi, I've removed sections that seem to need no further discussion, where you've suggested moving to separate threads, or where I'm just gonna roll over :-)
>
>> On Dec 22, 2014, at 10:56 AM, Steve Donovan  wrote:
> [...]
>>>>> -- 4.1.2, para 7: "If it selects a different algorithm, it MUST...:
>>>>>
>>>>> This is also true if it needs to announce some other feature that needs to be indicated.
>>>> SRD> This paragraph is talking specifically about algorithms and is needed because the AVP is optional.  Are you suggesting another sentence, another paragraph?  I'm guessing that the case you talk about is already covered elsewhere.
>>> We say this in 4.1.1 on reacting node behavior. We should make the same statement for reporting node behavior. This is the definitive section on reporting node behavior. If it's repeated elsewhere, we should consider whether _that_ text is redundant.
>> SRD> Again, this paragraph is dealing specifically with rules around which the algorithms supported by the reporting node interact with the OC-Features-Vector AVP.  The statement on other features is three paragraphs later.
> If you mean this paragraph:
>
> "  The reporting node SHOULD indicate support for other DOIC features
>     defined in extension drafts that it supports and that apply to the
>     transaction."
>
> Nothing in that (3 paragraphs later) paragraph says you MUST include OC-Features-Vector to do that. It's left for the reader to infer. We do explicitly say that for reacting nodes in 4.1.1.
SRD>  How about adding ..."it does so using the OC-Feature-Vector AVP" 
to the end of the above paragraph.
>
> [...]
>
>
>


From nobody Mon Dec 29 08:40:54 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EA11A8963 for ; Mon, 29 Dec 2014 08:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.579
X-Spam-Level: *
X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPKJueWr0EWp for ; Mon, 29 Dec 2014 08:40:49 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7BFB1A88B4 for ; Mon, 29 Dec 2014 08:40:49 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54289 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y5dN8-000Bql-1Z for dime@ietf.org; Mon, 29 Dec 2014 08:40:48 -0800
Message-ID: <54A1840D.5050403@usdonovans.com>
Date: Mon, 29 Dec 2014 10:40:45 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: dime@ietf.org
References: <0AF415BD-4AA8-4A4F-942B-29DA6C9E417B@nostrum.com> <549193B8.6000603@usdonovans.com>  <5491B2BB.30709@usdonovans.com> <3543DB65-DFC1-4ADE-8808-7B931F325F92@nostrum.com> <5491CE28.2020205@usdonovans.com> <0E11AEDD-6E90-4D61-8759-557B8596BAFB@nostrum.com> <54920B37.4060201@gmail.com> <2BE199F8-262D-40AB-A567-A857E94B3A6A@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D900066815235C94@DEMUMBX014.nsn-intra.net>  
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ocp1sRHEiARwAVf8Cl3wnoxsrgw
Subject: Re: [Dime] DOIC WGLC: duration unit
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Dec 2014 16:40:51 -0000

It appears that we are moving toward consensus to move back to seconds.  
If we do then I agree that a 24 hour maximum is reasonable.

Does anyone object to moving back to seconds with a 24 hour maximum?

Regards,

Steve

On 12/22/14 3:59 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> Dear all
>
> I am also ,in favor  to take the second as unit (according to Ben 's arguments), and also to have a upper limit. The limit that Ben gives is about 50 days. Is 24 hours too short?
>
> Best regards
>
> JJacques
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell
> Envoyé : vendredi 19 décembre 2014 00:47
> À : Wiehe, Ulrich (NSN - DE/Munich)
> Cc : dime@ietf.org
> Objet : Re: [Dime] DOIC WGLC: duration unit
>
> Hi Ulrich,
>
> You bring up a good point that we need to document the limits, or at least describe the implications of choosing to long or short of a duration either way. I suspect 1s is still too short for most situations, and  ( 2^32 - 1 / 1000 )s is probably still too long.
>
> (Don't get me wrong; I still think millisecond resolution for this is silly.)
>
> Thanks!
>
> Ben.
>
>> On Dec 18, 2014, at 11:11 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:
>>
>> Ben,
>>
>> my inclination is to change back to seconds. However, seconds allow a maximum value that is 1000 times higher and may be regarded unreasonably high. In a previous version of the draft we had an upper limit, and maybe when going back to seconds we should re-introduce an upper limit so that the protocol does not allow unreasonably long durations.
>>
>> Ulrich
>>
>>
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
>> Sent: Thursday, December 18, 2014 12:08 AM
>> To: Jouni Korhonen
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] DOIC WGLC: duration unit
>>
>>
>>> On Dec 17, 2014, at 5:01 PM, Jouni Korhonen  wrote:
>>>
>>> [snip]
>>>
>>>>> I'll step out of the argument and let someone else be champion for millisecond granularity.
>>>> Any other takers? Are there real use cases for sub-second precision?
>>> I do not really care. We changed that from seconds to milliseconds for some reason.. but no not see a reason to change it back either.
>> I'd argue that we should make it the "right thing", regardless of whether we changed it before. (Although remembering why might go far to answering my last question below.)
>>
>> I've describe why I think it is false precision, and can become harmful. To rephrase it, choosing too small of durations will cause harm by forcing rapid OLR updates (as in many per second.) These updates cause work for both reporting nodes and reacting nodes.
>>
>> We could offer guidance of how to avoid that harm. Or we could choose a resolution that makes it harder to cause such harm in the first place. I think good protocol design favors the later.
>>
>> Do you disagree with the potential for harm? Or do you see some use case for sub-second precision that I've missed?
>>
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


From nobody Mon Dec 29 08:43:30 2014
Return-Path: 
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B561A895A for ; Mon, 29 Dec 2014 08:43:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.778
X-Spam-Level: 
X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHga3_DTMzyv for ; Mon, 29 Dec 2014 08:43:27 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410AA1A896C for ; Mon, 29 Dec 2014 08:43:27 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54292 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (UNKNOWN:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Y5dPg-0002yY-4E; Mon, 29 Dec 2014 08:43:26 -0800
Message-ID: <54A184AB.8040109@usdonovans.com>
Date: Mon, 29 Dec 2014 10:43:23 -0600
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" ,  Ben Campbell , "dime@ietf.org list" 
References: <93DEBE9A-62A4-4637-9BF8-FFCD4195B115@nostrum.com> <54912AA6.2080706@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/DV0p8GOzzDePf5JbFiPcToBwt0Y
Subject: Re: [Dime] DOIC WGLC: Implicit values for OC-OLR
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Dec 2014 16:43:28 -0000

JJ,

I had already removed the paragraph based on no apparent objections.  Is 
this acceptable?

Regards,

Steve

On 12/22/14 3:54 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> Hi
>
> I think we can keep the current text as a general statement. This  does not prevmrt from indicating  more explicit meaning in future extensions if needed.
>
> Best regards
>
> JJacques
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
> Envoyé : mercredi 17 décembre 2014 08:03
> À : Ben Campbell; dime@ietf.org list; draft-ietf-dime-ovli@tools.ietf.org
> Objet : Re: [Dime] DOIC WGLC: Implicit values for OC-OLR
>
> OK with me.
>
> - Jouni
>
> 12/17/2014 7:11 AM, Ben Campbell kirjoitti:
>> (No, this is not the general rant on implicit values you from me :-)  )
>>
>> In section 6.3, paragraph 1, we have the following sentence:
>>
>> " The OC-OLR AVP does not explicitly contain all information needed by the reacting node to decide whether a subsequent request must undergo abatement using the received reduction percentage."
>>
>> I think this may vary by report type. For example, peer reports might need to include at least  some things explicitly that are implicit for host and realm reports. It's even different between host and realm reports. Therefore, I think we should remove it from this section, and put the specifics in the description of each report type.
>>
>>
>>
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>