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

From: Steve Donovan <[email-masked]>
Date: Sat, 05 Jul 2014 14:48:37 -0500

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: 	[email-masked]
To: 	Ben Campbell <[email-masked]>, "Steve Donovan" 
<[email-masked]>, Steve Donovan <[email-masked]>, 
"Ben Campbell" <[email-masked]>

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

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 07 Jul 2014 19:30:49 +0300

Thanks Steve putting -03 together. For the WG, please review the 
document. The document has reshaped quite a bit. It would be ideal if 
the next revision were close to final from the WG point of view.

- Jouni

7/5/2014 10:48 PM, Steve Donovan kirjoitti:
> 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:
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 11 Jul 2014 12:03:19 +0000

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:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Saturday, July 05, 2014 9:49 PM
To: [email-masked]
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: 
[email-masked]
To: 
Ben Campbell <[email-masked]>, "Steve Donovan" <[email-masked]>, Steve Donovan <[email-masked]>, "Ben Campbell" <[email-masked]>

Abstract:

The IETF Secretariat

---

From: Ben Campbell <[email-masked]>
Date: Fri, 11 Jul 2014 17:05:49 -0500

Hi Ulrich,

Thanks for the feedback!

We intended this draft as more of a discussion paper than something that the working group would publish. I will respond to some of your substantive comments inline. If we publish a new revision at some point, we can address the editorial and clarification comments at that time.

Thanks!

Ben.

On Jul 11, 2014, at 7:03 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]> wrote:

[...]

> 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…

I agree the scenarios in the draft are not exhaustive. We picked some that we think exercise certain behaviors, that are discussed in the scenarios and in the recommendations section. I believe they are all reasonable scenarios that DOIC should allow.

> 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…

Do I understand correctly that you mean that an agent MUST NOT remove or modify the OC-S-F from host routed requests? If so, I disagree. There are real world scenarios that will require that modification or removal. (For example, those in section 5.2)

> 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 t…

I agree in general, although I think we can separate the " what if this request gets throttled" behaviors from the "how you treat OC-S-F in forwarded requests" aspects.

> 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) fol…

[...]

> Should read "server". Agent overload is out of scope.

It is currently out of scope for the DOIC draft, but I believe it will eventually become in-scope for the working group. I'd prefer to keep things general to "node" in this section.  

> 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…

The knowledge that an agent performs server selection is, in itself, topology knowledge. In general, a node (TC or agent) selects the next hop. That hop might be a TS, or it might be an agent. There are scenarios in which a node cannot know which it is (e.g. certain proxies may be indistinguishable from servers.)

 I believe there are scenarios where an agent that is not the last hop before the TS could be configured to do diversion. That requires the "topology knowledge" that the set possible servers that might receive the overloaded request do not overlap with the set of possible servers that the request was diverted away from. I'm not saying those scenarios are common, or even a good idea--just that DOIC should not forbid them.

> 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…

I disagree. Use cases drive behaviors, not the other way around.

> 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 los…

I don't think we can solve the need for realm-type reports without allowing multiple OLRs. Once a server declares a host-overload condition, it will continue to send the host-report in every single answer until the overload condition ends. If the agent needs to insert a realm-report, it will have no where to put it unless we either let it remove one of the realm reports (which I think would be a bad idea) or let it insert another one.

I think it's worth discussion whether multiple OLRs in the same answer are allowed to have different algorithms. (But this particular aspect of that discussion would be a non-issue if the OLR included the selected algorithm, as I have previously argued.)

> 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 fi…

What do we gain by that limitation? Keep in mind, we are not suggesting that the DOIC draft specify how you build out networks--It should try really hard to avoid that. We only propose that the specified agent behaviors are flexible enough to handle the listed scenarios. 

> "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, th…

I think that goes into more details than we need to specifiy. Specifically, I don't think the type of the request changes whether an agent can change the supported features.

> 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-Feat…

I think we agree in general (although I think the last sentence is unnecessary.) But, until we have an end-to-end security mechanism (or add one to DOIC, which I hope we don't do) , trust relationships are really hop-by-hop. So the practical meaning is that you can tell the AVP was inserted (or validated--more on that in a second) by the peer vs something on the other side of that peer.

When I say "validated", I am talking about potential transitive trust relationship. That is, I know my peer supports DOIC, and I trust it to only send me stuff that it generated itself, or that it received from a peer that _it_ trusts.  (and so on.)

Since I can assume a peer that does _not_ support DOIC, will do neither, it really comes down to knowing whether my peer supports DOIC or not. Any further trust relationship has to be determined administratively. 

> 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…

I disagree. "Responsible for ensuring..." abatement is not the same as "responsible for performing abatement". In your example, the agent "ensures" abatement by delegating it to the source, which "performs" abatement.

In the context of a transaction, this is the only distinction between an agent that supports DOIC, but forwards OC-S-F without change, and one that does not support it at all.

But I think the trust issues from the previous comment are going to make this moot. If we are to distinguish a supporting agent from a non-supporting one that simply forwards unknown AVPs, then supporting agents are going to need to make _some_ modification to the OC-S-F prior to forwarding it. For example, it may need to insert it's diameter identity as a forwarding agent. If we go that route, there will be no such thing as a _supporting_ agent forwarding an OC-S-F AVP without change.)

> If the abatement is not "Diversion" and "Delegation" is possible, "Delegation" rather than "Throttling" must be done.

Why is this a requirement? If someone wants to deploy an agent that never delegates, we should not prevent them. I wouldn't build my network that way, but don't see why the IETF should put anything more than guidance about why delegation might be better.

(That said, it would be perfectly reasonable for 3GPP to require delegation whenever possible.)

> 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…

I agree that diversion typically cannot be done for host-routed requests, but I don't think we can say it "never" can. There are situations where an agent (or client) can divert host-routed requests. For example, you might have more than one physical server that can handle requests for the same Destination-Host value.

Otherwise, I don't see how your text disagrees with the text in the draft.

> 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…

I'm happy to call a modification a replacement. (Replacing an AVP with one that is similar to the original but slightly different is indistinguishable from modification.) But I don't think we (the IETF) can specify any formal limitations on how an agent can modify any OC-XXX without making perfectly reasonable network designs become illegal. Again, it's perfectly reasonable for 3GPP to add additional constraints.

(After working with Steve to put this draft together, I am no longer convinced that the "DOIC association" is useful as a formal concept. )

> 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 conta…

Again, I don't think we should forbid either approach at the IETF. Doing throttling as close to the client as possible is guidance, not a normative rule. Or at least nothing stronger than SHOULD strength.

(And again, 3GPP can add further constraints...)

---

From: Steve Donovan <[email-masked]>
Date: Sun, 13 Jul 2014 21:42:55 +0200

Ulrich,

Some comments inline.

Steve

> 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.
> 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…
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…
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 t…
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…
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 t…
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 Destina…
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) fol…
SRD> Minus D).
> 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 c…
SRD> Ok.
> 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 overl…
SRD> Ok.
> 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.
> 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…
SRD> I have nothing to add to Ben's response.
> 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…
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.
> 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 los…
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.
> 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 fi…
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.
> "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, th…
SRD> I agree with Ben's response.
> 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 conta…
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.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 15 Jul 2014 08:36:09 +0000

Hi Ben,

please see inline,

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Ben Campbell
Sent: Saturday, July 12, 2014 12:06 AM
To: [email-masked]
Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt

Hi Ulrich,

Thanks for the feedback!

Thanks!

Ben.

[...]

I agree the scenarios in the draft are not exhaustive. We picked some that we think exercise certain behaviors, that are discussed in the scenarios and in the recommendations section. I believe they are all reasonable scenarios that DOIC should allow.
[Wiehe, Ulrich (NSN - DE/Munich)] I'm ok with limited non-exhaustive example scenarios as long as A) to F) is followed.

Do I understand correctly that you mean that an agent MUST NOT remove or modify the OC-S-F from host routed requests? If so, I disagree. There are real world scenarios that will require that modification or removal. (For example, those in section 5.2)
[Wiehe, Ulrich (NSN - DE/Munich)] yes, you understand correctly, and no I do not agree with your "real world scenarios".

[...]

It is currently out of scope for the DOIC draft, but I believe it will eventually become in-scope for the working group. I'd prefer to keep things general to "node" in this section.  
[Wiehe, Ulrich (NSN - DE/Munich)] I'd prefer to keep things consistent. 

 I believe there are scenarios where an agent that is not the last hop before the TS could be configured to do diversion. That requires the "topology knowledge" that the set possible servers that might receive the overloaded request do not overlap with the set of possible servers that the request was diverted away from. I'm not saying those scenarios are common, or even a good idea--just that DOIC should not forbid them.
[Wiehe, Ulrich (NSN - DE/Munich)] "topology knowlege" seems to be too general; all that is needed is knowledge whether or not  the server is selected. A non-DOIC agents may not be able to know whether the selected next hop is a server or not (i.e. it selecst a server but is aware of this), DOIC-agents need to be aware.

I disagree. Use cases drive behaviors, not the other way around.
[Wiehe, Ulrich (NSN - DE/Munich)] The agent cannot arbitrarily chose the use case. The use case is determined by
a) request being host-routed or realm-routed
b) request containing/not containing an OC-S-F AVP
c) agent is configured to select the server for realm-routed requests

I don't think we can solve the need for realm-type reports without allowing multiple OLRs. Once a server declares a host-overload condition, it will continue to send the host-report in every single answer until the overload condition ends. If the agent needs to insert a realm-report, it will have no where to put it unless we either let it remove one of the realm reports (which I think would be a bad idea) or let it insert another one.
[Wiehe, Ulrich (NSN - DE/Munich)] I think it's a good idea to let the agent remove THE host-report and insert A realm-report. This reflects the principle of DOIC associations.

I think it's worth discussion whether multiple OLRs in the same answer are allowed to have different algorithms. (But this particular aspect of that discussion would be a non-issue if the OLR included the selected algorithm, as I have previously argued.)
[Wiehe, Ulrich (NSN - DE/Munich)] I would agree to have the selected algo within the OC-OLR rather than within the OC-S-F. This makes it easier to allow multiple OLRs, but again: I don't think it is strictly required to have multiple OLRs in the answer.

What do we gain by that limitation? Keep in mind, we are not suggesting that the DOIC draft specify how you build out networks--It should try really hard to avoid that. We only propose that the specified agent behaviors are flexible enough to handle the listed scenarios. 
[Wiehe, Ulrich (NSN - DE/Munich)] This limitation is needed to avoid lots of problems.

I think that goes into more details than we need to specifiy. Specifically, I don't think the type of the request changes whether an agent can change the supported features.
[Wiehe, Ulrich (NSN - DE/Munich)] Ist the other way rond: An agent that selects the server changes the type of request (from realm-routed to host-routed). It terminates the DOIC association downstream and opens a new DOIC association upstream, and therefore replaces the supported features.

In the context of a transaction, this is the only distinction between an agent that supports DOIC, but forwards OC-S-F without change, and one that does not support it at all.
[Wiehe, Ulrich (NSN - DE/Munich)] The concept of end-to-end piggybacking ensures that non-DOIC agents ensure abatement by delegation without being aware of it.

But I think the trust issues from the previous comment are going to make this moot. If we are to distinguish a supporting agent from a non-supporting one that simply forwards unknown AVPs, then supporting agents are going to need to make _some_ modification to the OC-S-F prior to forwarding it. For example, it may need to insert it's diameter identity as a forwarding agent. If we go that route, there will be no such thing as a _supporting_ agent forwarding an OC-S-F AVP without change.)
[Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. A supporting agent may decide to be transparent (see e.g. A) above). If so, it forwards OC-S-F without change (without modifying the identity of the node that inserted the OC-S-F (if we decide that the OC-S-F must include the identity of the node that inserts the OC-S-F)). 

(After working with Steve to put this draft together, I am no longer convinced that the "DOIC association" is useful as a formal concept. )
[Wiehe, Ulrich (NSN - DE/Munich)] The principle of DOIC associations is fundamental for the end-to-end piggybacking concept. This principle has been agreed and we should stick with it.

---

From: Steve Donovan <[email-masked]>
Date: Tue, 15 Jul 2014 14:16:19 +0200

Ulrich,

Can you be specific on which of the use cases in the specification do 
not need to be supported by the DOIC solution?

Thanks,

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 15 Jul 2014 14:06:13 +0000

Steve,

all use cases that do not follow A) to F),
e.g. where

C and S both supports DOIC, C sends a host-routed request to S and A in the path modifies OC-xxx AVPs (see figure 7). 

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Tuesday, July 15, 2014 2:16 PM
To: [email-masked]
Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt

Ulrich,

Thanks,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Tue, 15 Jul 2014 16:30:23 +0200

Ulrich,

Which of the use cases in the draft do not follow A) to F)?

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 15 Jul 2014 20:23:56 +0000

Steve,

e.g.the use case shown in figure 7 where the agent modifies the OC-S-F within the xxR no matter whether the xxR is host-routed or realm-routed. If xxR is host routed, A) is not followed.

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:[email-masked]] 
Sent: Tuesday, July 15, 2014 4:30 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt

Ulrich,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Wed, 16 Jul 2014 09:16:02 +0200

Ulrich,

The mismatched capabilities use case is required for extensibility.

We have at least two cases where the use case is required.  First is 
agent overload and the second is the rate abatement algorithm.

Consider the  agent overload feature.  This feature requires knowledge 
of whether or not the adjacent nodes support the feature. This cannot be 
achieved if the transaction client does not support the feature and the 
agent is not allowed to change the OC-S-F AVP.

As I indicated in my initial response, I do not agree with the A-F 
principles.  The DOIC solution needs to support required use cases. The 
behavior specified needs to be based on those use cases.

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 16 Jul 2014 09:00:50 +0000

Steve,

with regard to extensions introducing new algorithms like rate I do not see what is wrong with the A-F principles: Algorithm negotiation is end-to-end and it is irrelevant whether and which algorithms are supported by an agent in the middle.

With regard to agent overload, many things are unclear and my understanding is that nothing has been agreed so far. Please see my comments to your agent overload draft I sent earlier.
Principle here seems to be that agent overload information (capabilities and reports) is only relevant for the next hop and must not be forwarded further by the next hop (and if the next hop does not support agent overload, must not be sent at all to the next hop). Piggibacking this information on (end-to-end) application messages therefore may not be the best choice. Rather CER and WDR should be used for agent overload.  

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:[email-masked]] 
Sent: Wednesday, July 16, 2014 9:16 AM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt

Ulrich,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Wed, 16 Jul 2014 15:10:03 +0200

Ulrich,

Please see my comments inline

Steve

> with regard to extensions introducing new algorithms like rate I do not see what is wrong with the A-F principles: Algorithm negotiation is end-to-end and it is irrelevant whether and which algorit…
SRD> I  do not agree that algorithm negotiation is end-to-end. In 
addition, we should not preclude the case discussed in section 5.2.2.
> Principle here seems to be that agent overload information (capabilities and reports) is only relevant for the next hop and must not be forwarded further by the next hop (and if the next hop does n…
SRD> There are clearly options in how to design agent overload. My 
preference is to use the same mechanisms for transport of agent overload 
AVPs as are used for other report types.  Others might have different 
opinions.  We should not, however, assume a solution at this point.  In 
addition, we should not limit the options for future extensions.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Sat, 19 Jul 2014 07:29:38 +0000

Steve,

see my response inline.

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:[email-masked]] 
Sent: Sunday, July 13, 2014 9:43 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Cc: Rauschenbach, Uwe (NSN - DE/Munich)
Subject: Re: [Dime] Fwd: New Version Notification for draft-donovan-doic-agent-cases-00.txt

Ulrich,

Some comments inline.

Steve

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.
[Wiehe, Ulrich (NSN - DE/Munich)] I agree. So the clarification should read: "Diversion is specific to nodes (agents and clients) that perform server selection for realm-routed requests."
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.
[Wiehe, Ulrich (NSN - DE/Munich)] I disagree. The scenarios where it is reasonable for an agent to modify (better: replace) the OC-S-F AVP are limited to case where the request is realm-routed and the agent performs server selection. This is the only reasonable case where an agent in the middle terminates the (downstream) DOIC association and opens an independent (upstream) DOIC association.

[Wiehe, Ulrich (NSN - DE/Munich)] this is simple but misleading: there are also cases where the agent neither inserts an OC-S-F AVP nor does not insert an OC-S-F AVP, namely when the request does not survive throttling. 
[Wiehe, Ulrich (NSN - DE/Munich)] There are several reasons. But mainly to keep things simple and avoid problems we havn't solved so far. E.g. when the client sends some requests to the server via A1 and other requests via A2, OLRs seceived by the client will soon be out of sync. 
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.
[Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. An agent that receives a realm-routed request may be configured to just select the next hop (i.e. route to another agent which may be configured to perform server selection)
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.
[Wiehe, Ulrich (NSN - DE/Munich)] no. If no OC-S-F AVP is in the request then the request may be subject to throttling at the agent.
> 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) fol…
SRD> Minus D).
[Wiehe, Ulrich (NSN - DE/Munich)] no.
SRD> Ok.
SRD> Ok.
SRD> I have nothing to add to Ben's response.
[Wiehe, Ulrich (NSN - DE/Munich)] see my response to Ben (actually there was a typo in my response - should read "...but is not aware of ...")

[Wiehe, Ulrich (NSN - DE/Munich)] see my response to Ben.
[Wiehe, Ulrich (NSN - DE/Munich)] we are running into problems when this limitation is not in place. These problems should be avoided (by the limitation) or should be solved in the draft (currently they are not); 
SRD> I agree with Ben's response.
[Wiehe, Ulrich (NSN - DE/Munich)] see my response to Ben (typos again, sorry, should read: "Its the other way round: An agent that selects the server changes the type of report ... "
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.
[Wiehe, Ulrich (NSN - DE/Munich)] 
The concept of DOIC Endpoints and DOIC association between endpoints is fundamental and I think was agreed by the group. It was the basis for selecting the principle of end to end piggybacking OC-xxx AVPs on application messages. It seems that you are now going back to the hop-by-hop approch of the roach draft.