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

["Wiehe, Ulrich (NSN - DE/Munich)" <[e-mail]>]

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.

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:

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.

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.

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.

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.

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.

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.

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

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

10. clause 4. Overload Abatement Methods, 4th word:
Should read "server". Agent overload is out of scope.

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. 

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.

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.

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.

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

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.

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