Re: [Dime] Fwd: New Version Notification for draft-donovan-doic-agent-cases-00.txt

[Steve Donovan <[e-mail]>]

Ulrich,

Some comments inline.

Steve

On 7/11/14, 2:03 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve,
>
> Here are my comments:
>
> 1. Abstract 2nd sentence:
> The sentence should read: "A DOIC node is a Diameter node that in a given context may act as a reporting node or a reacting node."
> This is to align your definition "Any Diameter node that supports DOIC is a DOIC node" (see 1. Introduction, last paragraph) with our common understanding of the "end-to-end concept" which allows a DOIC node sitting between a supporting client and a supporting server to be transparent.
>
> 2. clause 1.1 Terminology and Abbreviations, Abating node:
> The definition should read: "A reacting node that locally performs overload abatement (i.e. throttling or diversion but not delegation)."
>
> 3. lots of colons missing in clause 1.1
>
> 4. clause 1.1 Terminology and Abbreviations, Overload Abatement:
> The definition should read: "...... Overload abatement actions may involve local traffic reduction, or delegation of actions towards the client (Delegation). Local traffic reduction can be achieved by either rejecting a request (Throttling) or by routing a request to a different destination (Diversion)."
>
> 5. clause 1.1 Terminology and Abbreviations, Diversion:
> I propose to add the following clarification:
> Diversion is specific to agents that perform server selection for realm-routed requests.
SRD> I disagree.  Diversion is also a valid abatement action that can be 
taken on realm-routed requests by a transaction client that has a direct 
transport connection to an overloaded transaction server.
>
> 6. clause 1.1 Terminology and Abbreviations:
> I propose to also define what Delegation is:
> "Delegation: Overload abatement through the delegation of action (Throttling) to a further downstream reacting node. Delegation is specific to agents that perform server selection for realm-routed requests, and is typically done when the agent detects that all available servers have requested load reduction, i.e. when receiving an answer message in response to a (not throttled) request that was forwarded to a selected server which in the answer reports an update of its overload information."
>
> 7. clause 2 Deployment Architectures
> There are many more architectures and scenarios which cannot all be covered separately. I therefore propose to focus on general principles that DOIC agents must follow independent from architecture and scenario. These principles are:
SRD> I agree that we need to resolve to general principles, but they 
need to address reasonable deployment architectures.  We cannot, and do 
not, know in advance the deployment architectures that will be 
implemented by users of the Diameter protocol.  In addition, we should 
not knowingly limit those deployment architectures in the way the 
protocol is designed.
>
> A) When an agent receives a host-routed request that contains an OC-S-F AVP, it takes no DOIC-specific action, i.e. it forwards the request to the next hop without removing, modifying or inserting OC AVPs; also no DOIC specific action is performed when receiving the corresponding answer. The agent may however store OLR information received in the answer for potential later use if it supports the features associated with the OLR.
SRD> I disagree.  I think the draft shows multiple reasons where it 
would be reasonable for an agent to modify  OS-S-F AVPs in a request 
message.
>
> B) When an agent receives a host-routed request that does not contain an OC-S-F AVP, it performs throttling according to a previously receive host-type OLR (if any).If the request survives (or no throttling was performed because no host-type OLR matched), the agent inserts an OC-S-F AVP and sends the request to the next hop. When receiving the corresponding answer, the agent checks whether it contains an OLR update and if so replaces the stored info (if any) with the updated info. In any case the agent removes the OLR from the answer before sending it to the previous hop.
SRD> The agent must have inserted OC-S-F AVPs in previous requests in 
order to receive an OC-OLR in an answer.  It feels like you are making 
in much more complex than needed and are trying to constrain user's of 
the Diameter protocol in the way overload can be handled.

SRD> It can be kept simple -- If an agent receives a request -- 
realm-routed or host-routed -- that does not contain a OC-S-F AVP then 
it SHOULD/MAP (strength of the requirement TBD) insert an OC-S-F AVP in 
the request message.  If local policy indicates that the agent is taking 
on responsibility for handling overload for non supporting transaction 
clients then the agent MUST insert an OC-S-F AVP in the request message.
>
> C) When an agent that is not configured to perform server selection for realm-routed requests receives a realm-routed request that contains an OC-S-F AVP, it takes no DOIC-specific action, i.e. it forwards the request to the next hop without removing, modifying or inserting OC AVPs; also no DOIC specific action is performed when receiving the corresponding answer. The agent may however store OLR information received in the answer for potential later use if it supports the features associated with the OLR.
SRD> There are scenarios where it should, based on local policy, modify 
the OC-S-F AVP, this was shown in the draft.  Why are you proposing to 
limit how a user of Diameter can manage overload in their networks?  Why 
do you propose that the rate algorithm cannot be turned on when 
transaction clients only support the loss algorithm?
>
> D) When an agent that is not configured to perform server selection for realm-routed requests receives a realm-routed request that does not contain an OC-S-F AVP, it performs throttling according to a previously receive realm-type OLR (if any).If the request survives (or no throttling was performed because no realm-type OLR matched), the agent inserts an OC-S-F AVP and sends the request to the next hop. When receiving the corresponding answer, the agent checks whether it contains an OLR update and if so replaces the stored info (if any) with the updated info. In any case the agent removes the OLR from the answer before sending it to the previous hop.
SRD> I'm not sure this is a valid scenario.  An agent that receives a 
realm-routed request must be configured to perform server selection.  
It's pretty useless otherwise.
>
> E) When an agent that is configured to perform server selection for realm-routed requests receives a realm-routed request that contains an OC-S-F AVP, it performs server selection, adds the Destination-Host AVP with the value identifying the selected server to the request (this need not be done when the selected server is an immediate peer), replaces the received OC-S-F AVP with its own OC-S-F AVP in the request and forwards the request to the next hop. When receiving the corresponding answer the agent checks whether it contains an OLR update and if so replaces the stored info (if any) with the updated info, calculates an (aggregated) realm-type OLR that fits to the supported features as received in the request. In any case the agent replaces the OC-S-F in the answer with its own OC-S-F (indicating the selected algorithm), removes the OC-OLR from the answer and adds its own calculated aggregated realm-type OLR (if any) to the answer before sending it to the previous hop.
SRD> On the service, this looks like the processing that should apply to 
all realm-routed requests, independent of the presence or absence of 
OC-S-F in the request.
>
> F) When an agent that is configured to perform server selection for realm-routed requests receives a realm-routed request that does not contain an OC-S-F AVP, logically a combination of case D) followed by case E) is performed.
SRD> Minus D).
>
> 8. clause 3. Diameter Routing, 3rd paragraph:
> Should read: "In general, throttling (Section 4) is the only local abatement technique that works for host-routed requests. Diversion (Section 4) is typically not possible, since only a single TS can handle any given host-routed request."
SRD> Ok.
>
> 9. clause 3. Diameter Routing, last sentence:
> Should read: "Since realm-routed requests are not bound to a particular TS, it is often possible for the node that selects the server to divert a number of them to other servers that are less overloaded."
SRD> Ok.
>
> 10. clause 4. Overload Abatement Methods, 4th word:
> Should read "server". Agent overload is out of scope.
SRD> I agree with Ben's response here.  Agent overload needs to be 
addressed and we need to make sure that the base DOIC spec doesn't make 
it impossible to add it in the future.
>
> 11. clause 4. Overload Abatement Method, 7th paragraph:
> Diversion (which is limited to realm-routed requests) can only occur at the Diameter Node that performs the server selection. Topology knowledge is not needed. Overload state knowledge actually is pushed further down the chain. The node can control how the received realm-routed request is routed upstream by inserting a Destination-Host AVP.
SRD> I have nothing to add to Ben's response.
>
> 12. clause 4. Overload Abatement Methods, last paragraph:
> "lease" should read "least"
>
> 13. clause 5. DOIC Use Cases:
> I have lots of detailed comments which I can share in a separate mail. The essence is that all the use cases described should follow the general principles A to F outlined above. It may be worth to totally rewrite this clause to illustrate the general principles A to F.
SRD> I don't agree with the general principles A to F so I don't agree 
with this section.  I also agree with Ben's response.  The use cases 
presented are all reasonable and the protocol needs to support them.  We 
should not be constraining how Diameter is used by limiting the 
reasonable deployment scenarios.
>
> 14. clause 6.1. General Recommendation, last paragraph:
> This is not strictly required. Multiple occurrences of OC-OLR could be regarded an an optimization. But then there are issues: when there are two OLRs in one answer, e.g. one realm-type OLR for loss and one host-type OLR for rate, we would also need two OC-S-F AVPs: one indicating that loss is selected, and one indicating that rate is selected. But this seems to be contradicting information.
SRD> I agree that there is a constraint in the current DOIC spec that 
would force all overload reports to apply to the same algorithm.  We 
need to make sure this is a reasonable constraint.  I do not agree that 
we can assume a single overload report in an answer message and the use 
cases presented clearly show this to be the case.
>
> 15. clause 6.2.1 Capabilities Exchange Behaviours, 3rd paragraph:
> Should read: "An agent may act as a reporting node on behalf of a non-supporting TS, or as reacting node on behalf of a non-supporting TC.[Section 5.3]". I'm not sure whether we should cover the first case. At least it should be limited to architectures where the agent (acting as reporting node on behalf of the non supporting server) and the (non supporting) server are immediate peers and the server has no other immediate peers, so that the two nodes can be regarded a single supporting server.
SRD> I don't see the need for such a limitation.  In the end, it should 
be up to the operator of the Diameter network to determine how to manage 
overload which includes which of those nodes are reporting nodes and 
which of those nodes are reacting nodes.
>
> 16. clause 6.2.1 Capabilities Exchange Behaviours, 4th paragraph:
> To add some clarificatios this should read:
> "An agent that acts as a reacting node must include an OC-Supported-Features in each Diameter request that it forwards in that role. If the inbound request included an OC-Supported-Features AVP, the agent may copy its content to the one in the outbound request (this is the case where the request is a) host-routed or b) realm-routed and the agent is not configured to perform server selection), or may replace the contents indicating the DOIC capabilities of the agent itself (this is the case where the request is realm routed and the agent is configured to perform server selection). If an inbound request does not contain an OC-Supported-Features AVP, the agent must insert one into the outbound request, indicating the DOIC capabilities of the agent itself."
SRD> I agree with Ben's response.
>
> 17. clause 6.2.1 Capabilities Exchange Behaviours, last paragraph:
> Should read: "An agent that does not support the DOIC mechanism is likely to forward an OC-Supported-Features AVP without modification. A DOIC node must be able to tell between an OC-Supported-Features AVP that was inserted by a node within a trusted domain, and one inserted by a node within a non-trusted domain.[Section 5.4]". This is because the reporting node (if it sends an OLR within an answer) sends it's OLR to the node that has inserted the OC-S-F AVP to the request.
>
> 18. clause 6.2.2 Overload Report Behaviours, 1st sentence, the part in brackets:
> I do not agree; when passing through, the responsibility is at the source, not at the relay. The sentence should read: "When a DOIC-supporting relay inserts or replaces an OC-Supported-Features AVP, it becomes responsible for ensuring that any OLRs it receives from upstream nodes are honored."
>
> 19. clause 6.2.2 Overload Report Behaviours, 2nd sentence:
> If the abatement is not "Diversion" and "Delegation" is possible, "Delegation" rather than "Throttling" must be done.
>
> 20. clause 6.2.2 Overload Report Behaviours, 2nd paragraph, last sentence:
> I do not agree. See also comment 11. Diversion is limited to realm-routed requests and can only be performed by nodes that do the server selection. These nodes can convert the realm-routed request to a host-routed request.
>
> 21. clause 6.2.2 Overload Report Behaviours, 3rd paragraph, last sentence:
> Modifying OLRs must follow strict rules. We either have
> a) one DOIC association betwee reacting node and reporting node where all agents in between are transparent and do not modify OC-xxx AVPs, or
> b) two independent DOIC associations, one between reacting node and agent (acting as reporting node) and one between the same agent (now acting as reacting node) and reporting node. Here the agent removes the received host-type OLR and inserts its own aggregated realm-type OLR. I would not call this a modification but a replacement. Modifications other than this may not be a good idea.
>
> 22. clause 6.2.2 Overload Report Behaviours, last but one paragraph:
> It is the other way round:
> An agent shall not throttle traffic locally when it has already sent (or will soon send) an OLR downstream (i.e. when it can or already has delegated the abatement). When receiving a xxR that contains an OC-S-F AVP (and the xxR matches an OLR) the agent can almost safely assume that this request survived an ongoing throttling downstream. The principle is that throttling should be done as close as possible to the client.
SRD> I have nothing to add to Ben's comments on the above with the 
exception that I also see little value to carrying the concept of a DOIC 
Endpoint forward.  Multiple Diameter nodes and and will need to perform 
abatement on a single overload report.  It won't only be an endpoint as 
previously conceived that does so.
>
> Regards,
> Ulrich
>
>
> From: DiME [mailto:[e-mail]] On Behalf Of ext Steve Donovan
> Sent: Saturday, July 05, 2014 9:49 PM
> To: [e-mail]
> Subject: [Dime] Fwd: New Version Notification for draft-donovan-doic-agent-cases-00.txt
>
> All,
>
> The below referenced draft focuses on a number of DOIC deployment scenarios involving agents.  The goal of this draft is to identify any new DOIC behaviors required to address these deployment scenarios.
>
> This directly addresses open issues #25, #27, #60 and #61 while indirectly addressing other open issues.
>
> Regards,
>
> Steve
>
> -------- Original Message --------
> Subject:
> New Version Notification for draft-donovan-doic-agent-cases-00.txt
> Date:
> Thu, 03 Jul 2014 09:17:11 -0700
> From:
> [e-mail]
> To:
> Ben Campbell <[e-mail]>, "Steve Donovan" <[e-mail]>, Steve Donovan <[e-mail]>, "Ben Campbell" <[e-mail]>
>
> A new version of I-D, draft-donovan-doic-agent-cases-00.txt
> has been successfully submitted by Steve Donovan and posted to the
> IETF repository.
>
> Name:		draft-donovan-doic-agent-cases
> Revision:	00
> Title:		Analysis of Agent Use Cases for Diameter Overload Information Conveyance (DOIC)
> Document date:	2014-07-03
> Group:		Individual Submission
> Pages:		34
> URL:            http://www.ietf.org/internet-drafts/draft-donovan-doic-agent-cases-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-donovan-doic-agent-cases/
> Htmlized:       http://tools.ietf.org/html/draft-donovan-doic-agent-cases-00
>
>
> Abstract:
>     The Diameter Overload Information Conveyance (DOIC) solution
>     describes a mechanism for exchanging information about Diameter
>     Overload among Diameter nodes.  A DOIC node is a Diameter node that
>     acts as either a reporting node are a reacting node.  A reporting
>     node originates overload reports, requesting reacting nodes to reduce
>     the amount of traffic sent.  DOIC allows Diameter agents to act as
>     reporting nodes, reacting nodes, or both, but does not describe agent
>     behavior.  This document explores several use cases for agents to
>     participate in overload control, and makes recommendations for
>     certain agent behaviors to be added to DOIC.
>
>                                                                                    
>
>
> 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.
>
> The IETF Secretariat
>
>
>
>