Subject: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt

From: [email-masked]
Date: Thu, 03 Jul 2014 12:31:24 -0700

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-03.txt
	Pages           : 48
	Date            : 2014-07-03

Abstract:
   This specification documents a Diameter Overload Control (DOC) base
   solution and the dissemination of the overload report information.

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

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

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: Steve Donovan <[email-masked]>
Date: Sat, 05 Jul 2014 14:42:04 -0500

All,

This version of the DOIC draft is a restructuring of previously agreed 
to content.

The master plan for the restructuring is in Appendix C.  This outlines 
where material from -02 was moved in -03.

For those interested, the work was done in steps, with a snapshot for 
each step available here:

https://github.com/jounikor/draft-docdt-dime-ovli

Each step has the name draft-ietf-dime-ovli-03-nn-text.txt

where nn indicates the subversion and "text" indicates the focus for 
that subversion.

The next step will be to resolve open issues already identified and 
those yet those yet to be identified.

Regards,

Steve

On 7/3/14, 2:31 PM, [email-masked] wrote:
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 14 Jul 2014 20:33:16 +0000

Hi Steve,
here are my comments.
They focus on new text you introduced. I agree that restructuring may require new text, however, I believe that with the new text a new concepts is introduced which macerates the agreed end-to-end concept and allows all DOIC agents on the path to do what they wants, so that we end up in a hop-by-hop concept.

1. clause 2.3, second paragraph:
Should read: "Reacting nodes indicate support for DOIC by including the OC-Supported-Features AVP into all request messages originated or relayed by the Reacting node."

2. clause 2.3, 3rd paragraph, 1st sentence:
OC-xxx AVPs must not be included in an answer message when the corresponding request did not contain an OC-S-F AVP.

3. clause 3.3, 7th paragraph:
Should read "The reporting node only includes an indication of support for one overload abatement algorithm.  This is the algorithm that the reporting node intends to use should it enter an overload condition or requests to use while it actually is in 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."

4. clause 3.3, 10th paragraph:
The 1st sentence is misleading. In the general case, agents on the path between reacting node and reporting node are transparent. I agree that there are exceptions to the general case where an agent on the path is not transparent, but then the agent IS the reporting node (reporting to the sender of the request) and it also IS the reacting node (reacting on reports received from the upstream reporting node).  
The first 3 words of the second sentence "in this case" need clarification: "In the case where an agent takes the role of a reporting node (reporting to the downstream reacting node) and at the same time takes the role of a reacting node (reacting on reports received from an upstream reporting node)".
Last sentence: Its not an update but a replacement. The two DOIC associations are handled independently.

5. clause 3.3, last paragraph:
General rules shall be followed for each of the two associations separately. The content of the OC-S-F AVP sent by the agent upstream should reflect what the agent is able and willing to support (as always).

6. clause 3.4, 2nd paragraph:
Should read: "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."

7. clause 3.4, 4th paragraph, 2nd sentence:
I cannot understand this sentence. Probably only simple typos but I don't know. 

8. clause 3.4, 4th paragraph last 2 sentences:
I don't understand and probably do not agree.

9. clause 3.5, 3rd paragraph, last word:
Should read "communicated"

10. clause 3.5, 4th paragraph, 1st sentence:
I don't understand. I can understand: "Reporting nodes use the OC-OLR AVP to communicate overload occurances towards reacting nodes."

11. clause 4.1, 3rd paragraph, last 4 words:
may be misleading. A DOIC supporting agent sitting between DOIC supporting client and DOIC supporting Server is transparent with regard to DOIC. This agent does not indicate DOIC support.

12. clause 4.1, 4th paragraph, 2nd sentence:
Should read:"If a request message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent inserts the AVP."

13. clause 4.1, last sentence:
Should read "If the message already has the AVP then the agent either leaves it unchanged in the relayed message or replaces it to reflect the features the agent is able and willing to support." Clarification is needed to say that strict rules must be followed by the agent to select the correct option. These rules take into account whether the request is host-routed or relam-routed and whether the agent is configured to select the server for realm-routed requests.

14. clause 4.1.2, 2nd paragraph:
Should read: "Based on the content of the OC-Supported-Features AVP in the request message, the reporting node knows what overload control functionality is supported by the reacting node.  The reporting node then acts accordingly for the subsequent answer messages it initiates for the transaction."
  
15. clause 4.1, 4th paragraph, 2nd sentence, 17th word:
Should read: "message's"

16. clause 4.1, 6th paragraph:
This should be left to the (future) specification that introduces other DOIC features.

17. clause 4.1, 7th paragraph, last 6 words:
should be based on requiements set by the (future) specification that introduces other DOIC features 

18. clause 4.1, 8th paragraph, last sentence:
Should read: "Lack of the OC-Supported-Features AVP in the request message indicates that there is no downstream reacting node for the transaction."

19. clause 4.1, last sentence:
Should read: "An agent MAY replace the OC-Supported-Features AVP carried in answer messages." This replacement must follow general rules. Its not so that the agent may do what ever it wants to. The decision must be based on whether or not the agent has replaced the OC-S-F in the corresponding request.

20. clause 5.2, 1st sentence:
Should read: "A reporting node using the loss algorithm must use the OC-Reduction-Percentage AVP (Section 6.7) to indicated the desired percentage of traffic reduction."

21. clause 5.2, last sentence:
Should read: "Editor's note: The above duplicates what is in the OC-Reduction-Percentage AVP section and can probably be removed."

22. clause 5.4, 6th paragraph:
Should read: "If the reacting node does not receive a an OLR in the answer that corresponds to the probe request messages sent to the formally overloaded node then the reacting node should slowly increase the rate of traffic sent to the overloaded node."

Best regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Saturday, July 05, 2014 9:42 PM
To: [email-masked]
Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt

All,

Regards,

Steve

---

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

Ulrich,

Thanks for the comments.  Please see my responses inline.

Regards,

Steve
> They focus on new text you introduced. I agree that restructuring may require new text, however, I believe that with the new text a new concepts is introduced which macerates the agreed end-to-end…
SRD> We have never had an agreement on end-to-end versus hop-by-hop and 
I believe that we will end up with a hybrid of the two.  We have open 
issues on agent behavior that Ben and I are attempting to address with 
the agent cases draft.

SRD> That said, this type of restructuring of the document is likely to 
put agreed to behavior in a new light.  If there are cases where I have 
implied changes to agreed to normative behavior, or if the informative 
text is not accurate, then these things need to be corrected.
> Should read: "Reacting nodes indicate support for DOIC by including the OC-Supported-Features AVP into all request messages originated or relayed by the Reacting node."
SRD> You mean clause 3.2.  I agree with the change.
> OC-xxx AVPs must not be included in an answer message when the corresponding request did not contain an OC-S-F AVP.
SRD> Agreed.
> Should read "The reporting node only includes an indication of support for one overload abatement algorithm.  This is the algorithm that the reporting node intends to use should it enter an overloa…
SRD. OK.
> Last sentence: Its not an update but a replacement. The two DOIC associations are handled independently.
SRD> I don't know what you mean when you say an agent is transparent.  
Agents must take an active role in even the most basic case for overload 
handling to work, so they cannot be transparent.
> General rules shall be followed for each of the two associations separately. The content of the OC-S-F AVP sent by the agent upstream should reflect what the agent is able and willing to support (a…
SRD> What two associations?  Is there one association (end-to-end) or is 
the an association on both sides of the agent (hop-by-hop)?  Or is there 
an association that involves three entities, the reporting node, an 
agent reacting node for realm-routed requests and a transaction-client 
reporting node for handling host-routed requests?
> Should read: "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 algorith…
SRD> The sequence number is being used as an overload report ID. I can 
make the change but I don't see it as necessary.
> I cannot understand this sentence. Probably only simple typos but I don't know.
SRD> Yes, a typo (this instead of the) and awkward wording.  How about 
"This applies to requests that contain the Destination-Host AVP with a 
DiameterIdentity that matches the overload report.
> I don't understand and probably do not agree.
SRD> See above.
> Should read "communicated"
SRD> Agreed.
> I don't understand. I can understand: "Reporting nodes use the OC-OLR AVP to communicate overload occurances towards reacting nodes."
SRD> Who else would reports be sent to?
> may be misleading. A DOIC supporting agent sitting between DOIC supporting client and DOIC supporting Server is transparent with regard to DOIC. This agent does not indicate DOIC support.
SRD> I disagree.
> Should read:"If a request message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent inserts the AVP."
SRD> That is what it already says.
> Should read "If the message already has the AVP then the agent either leaves it unchanged in the relayed message or replaces it to reflect the features the agent is able and willing to support." Cl…
SRD> This is a topic on agent behavior that is addressed in the agent 
cases draft.  I'll leave the discussion for what the wording should be 
to the discussion on that draft.
> Should read: "Based on the content of the OC-Supported-Features AVP in the request message, the reporting node knows what overload control functionality is supported by the reacting node.  The repo…
SRD> It would be easier if you didn't make it difficult to understand 
the change you are proposing.  I think you are proposing changing 
node(s) to node.  I don't agree but that will be addressed as part of 
the agent cases discussion.
> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word:
SRD> I'm assuming you mean section 4.1.2.  I agree to the change.
> should be based on requiements set by the (future) specification that introduces other DOIC features
SRD> Again, clause 4.1.2 -- I don't understand the issue when these two 
paragraphs are taken together.
> Should read: "Lack of the OC-Supported-Features AVP in the request message indicates that there is no downstream reacting node for the transaction."
SRD> I think you mean clause 4.1.2.  I don't see the need for the change.
> Should read: "An agent MAY replace the OC-Supported-Features AVP carried in answer messages." This replacement must follow general rules. Its not so that the agent may do what ever it wants to. The…
SRD> What is the difference between modify and replace?  I am ok with 
removing this statement until we have the agent behavior discussion.  I 
thought I had taken the agent specific statements out of this version.
> Should read: "A reporting node using the loss algorithm must use the OC-Reduction-Percentage AVP (Section 6.7) to indicated the desired percentage of traffic reduction."
SRD> Agreed.
> Should read: "Editor's note: The above duplicates what is in the OC-Reduction-Percentage AVP section and can probably be removed."
SRD> Yes, bad wording.  The note will be removed, bad wording and all, 
once there is a discussion on if this is redundant.
> Should read: "If the reacting node does not receive a an OLR in the answer that corresponds to the probe request messages sent to the formally overloaded node then the reacting node should slowly i…
SRD Agreed, this is more clear.

---

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

Steve,
please see my response inline.

Regards
Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Tuesday, July 15, 2014 3:53 PM
To: [email-masked]
Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt

Ulrich,

Regards,

Steve
SRD> We have never had an agreement on end-to-end versus hop-by-hop and 
I believe that we will end up with a hybrid of the two.  We have open 
issues on agent behavior that Ben and I are attempting to address with 
the agent cases draft.
[Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop approach of the roach draft was reason not to proceed with that draft.

> Should read: "Reacting nodes indicate support for DOIC by including the OC-Supported-Features AVP into all request messages originated or relayed by the Reacting node."
SRD> You mean clause 3.2.
[Wiehe, Ulrich (NSN - DE/Munich)] yes
  I agree with the change.
SRD> Agreed.
SRD. OK.
SRD> I don't know what you mean when you say an agent is transparent.  
Agents must take an active role in even the most basic case for overload 
handling to work, so they cannot be transparent.
[Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not support DOIC are transparent. Agents that support DOIC in most cases behave like non supporting agents.
SRD> What two associations?  Is there one association (end-to-end) or is 
the an association on both sides of the agent (hop-by-hop)?  Or is there 
an association that involves three entities, the reporting node, an 
agent reacting node for realm-routed requests and a transaction-client 
reporting node for handling host-routed requests?
[Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1,
There is one association between C and A, and one association between A and S. Both associations are "end-to-end" as there may be transparent (supporting or non-supporting) agents in the middle. 
SRD> The sequence number is being used as an overload report ID. I can 
make the change but I don't see it as necessary.
[Wiehe, Ulrich (NSN - DE/Munich)] please make the change.
SRD> Yes, a typo (this instead of the) and awkward wording.  How about 
"This applies to requests that contain the Destination-Host AVP with a 
DiameterIdentity that matches the overload report.
[Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that contain a DiameterIdentity in the Destination-Host AVP that matches the reporting host's DiameterIdentity"
SRD> See above.
SRD> Agreed.
SRD> Who else would reports be sent to?
[Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement algorithm but the reporting node that uses the OC-OLR AVP to communicate overload occurances.
> may be misleading. A DOIC supporting agent sitting between DOIC supporting client and DOIC supporting Server is transparent with regard to DOIC. This agent does not indicate DOIC support.
SRD> I disagree.
[Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Should be: ...This agent does not indicate its DOIC support, rather it transparently forwards the client's DOIC support.
SRD> That is what it already says.
[Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message...
[Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing two sentences? The proposal is to insert "is" between "functionality" and "supported", to add "the" between "by" and "reacting", to replace "node(s)" with "node", and to insert "for the transaction" after "initiates".   
> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word:
SRD> I'm assuming you mean section 4.1.2.
[Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, and 19.
  I agree to the change.
SRD> I think you mean clause 4.1.2.  I don't see the need for the change.
[Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not correct. It should either read: "Lack of the OC-Supported-Feature AVP in the request message indicates to the reporting node that there is no reacting node for the transaction" or as proposed above.
SRD> What is the difference between modify and replace?  I am ok with 
removing this statement until we have the agent behavior discussion.  I 
thought I had taken the agent specific statements out of this version.
[Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with identical values. You remove what has been received in and insert your own stuff.
SRD> Agreed.

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 20 Jul 2014 21:55:32 +0300

Some comments inline..

> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not support DOIC are transparent. Agents that support DOIC in most cases behave like non supporting agents.

I am towards Ulrich's view here. Even for an agent that understands DOIC 
it is up to the local policy whether it is transparent or takes an 
active role.

> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change.

OK to do the change.

> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that contain a DiameterIdentity in the Destination-Host AVP that matches the reporting host's DiameterIdentity"

I would be inclined to keep the text Steve proposed. But both are ok 
actually.

> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement algorithm but the reporting node that uses the OC-OLR AVP to communicate overload occurances.

Agree.

> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Should be: ...This agent does not indicate its DOIC support, rather it transparently forwards the client's DOIC support.

Agree with Ulrich on the intent of agent behavior but not with the 
proposed text change.

> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message...

OC-Supported-Features can be in both request and answer, thus "If a 
message" in that sense is correct.

> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing two sentences? The proposal is to insert "is" between "functionality" and "supported", to add "the" between "by" and "reacting", t…

Agree with the proposed change.

> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not correct. It should either read: "Lack of the OC-Supported-Feature AVP in the request message indicates to the reporting node that…

I don't see a reason for the change. Original text seem correct to me.

> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with identical values. You remove what has been received in and insert your own stuff.

Agent (proxy) can always do that i.e. modify the APV contents. Obviously 
if an agent tampers the OC-Supported-Features AVP it needs to know what 
it is doing. In general agree with the clarification but not with the 
proposed text.

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Sun, 20 Jul 2014 16:24:54 -0400

> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing two sentences? The proposal is to insert "is" between "functionality" and "supported", to add "the" between "by" and "reacting", t…
It would be much easier if you included both the original text and the 
proposed change.  It can sometimes be difficult to find the original 
text, especially when the incorrect section number is given.  Some 
changes are also subtle when having to switch between the document and 
email.  Having both in the email makes it easier to understand the 
proposed changes.

---

From: Steve Donovan <[email-masked]>
Date: Sun, 20 Jul 2014 16:38:25 -0400

I've removed most of the message to focus on one of Ulrich's comments.

>>> The 1st sentence is misleading. In the general case, agents on the 
>>> path between reacting node and reporting node are transparent. I 
>>> agree that there are exceptions to the general case where an agent 
>>> on the path is not transparent, but then the agent IS the reporting 
>>> node (reporting to the sender of the request) and it also IS the 
>>> reacting node (reacting on reports received from the upstream 
>>> reporting node).
>>> The first 3 words of the second sentence "in this case" need 
>>> clarification: "In the case where an agent takes the role of a 
>>> reporting node (reporting to the downstream reacting node) and at 
>>> the same time takes the role of a reacting node (reacting on reports 
>>> received from an upstream reporting node)".
>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not 
>> support DOIC are transparent. Agents that support DOIC in most cases 
>> behave like non supporting agents.
>
> I am towards Ulrich's view here. Even for an agent that understands 
> DOIC it is up to the local policy whether it is transparent or takes 
> an active role.
>
I think I agree with Jouni's statement that whether a DOIC agent is 
"transparent" is up to local policy.  I need someone to formally define 
transparent before I can fully agree.  If transparent means equivalent 
in behavior to a non DOIC agent, which I think Ulrich is implying, then 
I do not agree.

I would assert that a DOIC agent's behavior is never the same as a non 
DOIC agent.  A DOIC agent must always check for presence of the 
OC-Supported-Features AVP in request messages, and if it is not present, 
it should insert one.  This is clearly governed by local policy but the 
requirement that an agent be able to handle abatement for a non 
supporting transaction client makes this behavior necessary.

---

From: Steve Donovan <[email-masked]>
Date: Sun, 20 Jul 2014 16:47:28 -0400

Original email trimmed to focus on one point.

>>> General rules shall be followed for each of the two associations 
>>> separately. The content of the OC-S-F AVP sent by the agent upstream 
>>> should reflect what the agent is able and willing to support (as 
>>> always).
>> There is one association between C and A, and one association between 
>> A and S. Both associations are "end-to-end" as there may be 
>> transparent (supporting or non-supporting) agents in the middle.
While I thought I understood what a DOIC association was, I am now 
confused by the concept.

My interpretation originally was that there were associations between 
any two DOIC nodes and that it was a way of addressing the need for DOIC 
signalling to cross non supporting nodes.

I think Ulrich's interpretation is that an association is between a 
reporting and a reacting node.

Either way, I don't see the concept as adding value.  There is no 
behavior associated with an association.  Behavior is instead associated 
capability advertisement and with overload reports.

I'm inclined to say we should remove the concept entirely.

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 21 Jul 2014 03:24:35 +0300

Steve,

> in behavior to a non DOIC agent, which I think Ulrich is implying, then

Agree that "transparent" is a bit bad wording here, because for me at 
least "transparent proxies" have a strong existing behavioral model 
(from HTTP proxies that is..).

For me the DOIC agent behaviour should be the following (by local 
configuration etc):

1) the DOIC feature is turned off. The agent behaves like
    non-DOIC enabled agent.

2) the DOIC feature is on and the local policy says the agent
    check every message to apply the DOIC thing. This could
    be e.g. behaving as an endpoint for non-supporting nodes.

3) the DOIC feature is on but the local policy selectively
    picks up the messages it needs to apply the DOIC thing
    (this could be handled e.g. based on ACLs on both IP
    and Diameter level). Otherwise the same as 2)

For cases 2) and 3) whether the agent inserts e.g. a missing 
OC-Supported-Feature for a message that otherwise falls into those that 
need DOIC to be applied is again a local policy.

- Jouni

> supporting transaction client makes this behavior necessary.

Anyway, could we say (and agree) that a DOIC enabled agent

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Mon, 21 Jul 2014 04:08:20 +0000

+1 for the following aspect.

>>> Agents must take an active role in even the most basic case for 
>>> overload handling to work, so they cannot be transparent.

>I am towards Ulrich's view here. Even for an agent that understands DOIC it is up to the local policy whether it is transparent or takes an active role.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Monday, July 21, 2014 12:26 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; [email-masked]
Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt

Some comments inline..

7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti:
> SRD> We have never had an agreement on end-to-end versus hop-by-hop 
> SRD> and
> SRD> That said, this type of restructuring of the document is likely 
> SRD> to
> put agreed to behavior in a new light.  If there are cases where I 
> have implied changes to agreed to normative behavior, or if the 
> informative text is not accurate, then these things need to be corrected.
>>
> Agents must take an active role in even the most basic case for 
> overload handling to work, so they cannot be transparent.

I am towards Ulrich's view here. Even for an agent that understands DOIC it is up to the local policy whether it is transparent or takes an active role.

> SRD> What two associations?  Is there one association (end-to-end) or 
> SRD> is
> the an association on both sides of the agent (hop-by-hop)?  Or is 
> there an association that involves three entities, the reporting node, 
> an agent reacting node for realm-routed requests and a 
> transaction-client reporting node for handling host-routed requests?
> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, There is 
> one association between C and A, and one association between A and S. Both associations are "end-to-end" as there may be transparent (supporting or non-supporting) agents in the middle.
>>

OK to do the change.

> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that contain a DiameterIdentity in the Destination-Host AVP that matches the reporting host's DiameterIdentity"

I would be inclined to keep the text Steve proposed. But both are ok actually.

Agree.

> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Should be: ...This agent does not indicate its DOIC support, rather it transparently forwards the client's DOIC support.

Agree with Ulrich on the intent of agent behavior but not with the proposed text change.

> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message...

OC-Supported-Features can be in both request and answer, thus "If a message" in that sense is correct.

> SRD> Again, clause 4.1.2 -- I don't understand the issue when these 
> SRD> two

> removing this statement until we have the agent behavior discussion.  
> I thought I had taken the agent specific statements out of this version.

Agent (proxy) can always do that i.e. modify the APV contents. Obviously if an agent tampers the OC-Supported-Features AVP it needs to know what it is doing. In general agree with the clarification but not with the proposed text.

- Jouni

>> This version of the DOIC draft is a restructuring of previously 
>> agreed to content.
>>
>> The master plan for the restructuring is in Appendix C.  This 
>> outlines where material from -02 was moved in -03.
>>
>>> 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.
>>>

---

From: Steve Donovan <[email-masked]>
Date: Mon, 21 Jul 2014 09:15:32 -0400

Ok, let's see if it's possible to completely turn off all DOIC behavior 
in agents and still be able to reduce traffic to a server that sends a 
host overload report.

Assume the following agent based deployment:

                 +--+
              /--|s1|
   +-+  +-+  /   +--+
   |c|--|a|==     ...
   +-+  +-+  \   +--+
              \--|sn|
                 +--+

Assume that there is a large number of servers, say 50.

Now, assume that the Diameter application in question exclusively uses 
realm-routed requests - 100% of requests sent by the client do NOT have 
a destination-host AVP.

Now assume that server s1 sends an host type overload report requesting 
a reduction of 20% using the loss algorithm.

Also assume that the unused capacity in servers s2 through s50 is 
sufficient to handle the traffic that would have been sent to s1. As 
such, there is no reason to throttle any requests.

There are no host routed requests for this application and the client 
does not have a direct transport connection to server s1. The only 
option a client has is to hand the request off to the agent for routing.

The proposal in the agent cases draft is that the agent diverts 20% of 
the realm routed requests that would have been sent to server s1 to 
servers s2 through s50.

If DOIC behavior is turned off in the agent then how will the traffic 
routed to s1 be reduced?

Steve

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Mon, 21 Jul 2014 13:36:01 +0000

Steve,

In the example below, you are assuming that "any server can serve any subscriber session".
However, if that is not the case then the agent has no choice but to route the request to the appropriate server, irrespective of its used/unused capacity.

The point being, "the DOIC supporting agent must take an active role" is not accurate/correct.
It is based on other factors and finally on local policy.

Regards,
Nirav.

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]] 
Sent: Monday, July 21, 2014 6:46 PM
To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Transparent agents (was Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt)

Ok, let's see if it's possible to completely turn off all DOIC behavior in agents and still be able to reduce traffic to a server that sends a host overload report.

                 +--+
              /--|s1|
   +-+  +-+  /   +--+
   |c|--|a|==     ...
   +-+  +-+  \   +--+
              \--|sn|
                 +--+

Now, assume that the Diameter application in question exclusively uses realm-routed requests - 100% of requests sent by the client do NOT have a destination-host AVP.

Now assume that server s1 sends an host type overload report requesting a reduction of 20% using the loss algorithm.

Also assume that the unused capacity in servers s2 through s50 is sufficient to handle the traffic that would have been sent to s1. As such, there is no reason to throttle any requests.

There are no host routed requests for this application and the client does not have a direct transport connection to server s1. The only option a client has is to hand the request off to the agent for routing.

The proposal in the agent cases draft is that the agent diverts 20% of the realm routed requests that would have been sent to server s1 to servers s2 through s50.

If DOIC behavior is turned off in the agent then how will the traffic routed to s1 be reduced?

Steve

On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote:
>> issues on agent behavior that Ben and I are attempting to address 
>> with the agent cases draft.
>> there an association that involves three entities, the reporting 
>> node, an agent reacting node for realm-routed requests and a 
>> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, There 
>> is one association between C and A, and one association between A and S. Both associations are "end-to-end" as there may be transparent (supporting or non-supporting) agents in the middle.
>> SRD> The sequence number is being used as an overload report ID. I 
>> SRD> can
>> SRD> Yes, a typo (this instead of the) and awkward wording.  How 
>> SRD> about
>> "This applies to requests that contain the Destination-Host AVP with 
>> a DiameterIdentity that matches the overload report.
>> cases draft.  I'll leave the discussion for what the wording should 
>> be to the discussion on that draft.
>> SRD> Yes, bad wording.  The note will be removed, bad wording and 
>> SRD> all,
>>> For those interested, the work was done in steps, with a snapshot 
>>> for each step available here:
>>>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 21 Jul 2014 13:47:55 +0000

Steve,

The example you show is absolutely valid and 100% inline with A) to F) - (assuming that all servers can serve any request).
However, there are other scenarios like:

                        +--+
                     /--|s1|
 +-+    +--+  +--+  /   +--+
 |c|--- |a1|--|a2|==     ...
 +-+    +--+  +--+  \   +--+
                     \--|sn|
                        +--+

Here I think a1 should be transparent even when DOICable.
a1 does not take the role of a reacting node since c supports DOIC.
a1 does not perform server selection and therefore does not take the role of a reporting node (for realm-reports).

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:[email-masked]] 
Sent: Monday, July 21, 2014 3:16 PM
To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Transparent agents (was Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt)

                 +--+
              /--|s1|
   +-+  +-+  /   +--+
   |c|--|a|==     ...
   +-+  +-+  \   +--+
              \--|sn|
                 +--+

Steve

---

From: <[email-masked]>
Date: Mon, 21 Jul 2014 14:28:30 +0000

Assuming that any server can process any request at any time, I would say that the scenario below is a simple illustration for a dynamic weight/load balancer, right?

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Nirav Salot (nsalot)
Envoyé : lundi 21 juillet 2014 15:36
À : Steve Donovan; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Objet : Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt)

Steve,

Regards,
Nirav.

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]] 
Sent: Monday, July 21, 2014 6:46 PM
To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Transparent agents (was Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt)

                 +--+
              /--|s1|
   +-+  +-+  /   +--+
   |c|--|a|==     ...
   +-+  +-+  \   +--+
              \--|sn|
                 +--+

Steve

_________________________________________________________________________________________________________________________

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.

---

From: Steve Donovan <[email-masked]>
Date: Mon, 21 Jul 2014 10:29:17 -0400

Ulrich,

I am not arguing that all agents should take an active role in the 
handling of all overload reports.  What I am arguing is that there are 
scenarios where an agent must take an active role in DOIC to ensure that 
a requested reduction in traffic an be achieved.

For DOIC to work a carrier cannot turn off all DOIC behavior in agents, 
as suggested by Jouni.

I agree that in your scenario below, a1 does not need to take an active 
role in reducing traffic when c supports DOIC.  a1 should take an active 
role when c does not support DOIC.  The problem is that a1 does not know 
in advance whether c supports DOIC so it will need to inspect all 
transactions for the presence of OC-S-F to determine if it needs to 
handle overload reports for a non supporting client.

Does that mean a1 is transparent if it inspects all requests and does 
nothing in the case where there is c supports DOIC?

Does transparent mean that there is no observable difference in the DOIC 
AVPs that pass through the agent or does it mean that there is no 
observable difference in how transactions are handled by the DOIC agent?

I'm guessing that we have multiple assumptions on what transparent means 
and, if we are going to continue saying agents should be transparent 
then we need a definition of transparent.

I think for this use case, we need the following normative statements in 
the draft for handling of abatement of realm-routed requests?  I think 
this is general behavior and should go in the section on handling of 
overload reports.

"DOIC nodes with a direct transport connection to a reporting node that 
has an active overload report must handle abatement of realm-routed 
requests.  The preferred method for handling abatement of realm-routed 
requests is diversion, where the node with the direct transport 
connection routes the request to an alternative server that is able to 
handle the request.  If there is no alternative server with the needed 
capacity to handle the request then the DOIC node must/should throttle 
the necessary requests to meet the requested reduction in traffic."

If we can agree on this then we can move on to the next agent based use 
case.

Regards,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Mon, 21 Jul 2014 10:42:44 -0400

Lionel,

Only if the thing called a dynamic weight/load balancer understands 
Diameter.

The point I'm trying to make is that the Diameter node that has a direct 
connection to an overloaded server, be that a client, an agent, a proxy 
or a Diameter load balancer, MUST take part in abatement of traffic 
being routed to an overloaded server.

This is not optional, as pointed out in the other message I sent this 
morning.

Steve

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 21 Jul 2014 17:53:22 +0300

Steve,

> For DOIC to work a carrier cannot turn off all DOIC behavior in agents,

Why? If you have a hierarchy of agents I don't see a reason why some of 
those could be just "vanilla agents" or DOIC agents with functionality 
turned off. Not arguing such deployment makes sense but the protocol 
solution should be able to cope with that.

- Jouni

>> The example you show is absolutely valid and 100% inline with A) to F)
>> - (assuming that all servers can serve any request).
>> a1 does not perform server selection and therefore does not take the
>> role of a reporting node (for realm-reports).
>>
>> Ulrich
>>
>>
>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do
>>>>> not support DOIC are transparent. Agents that support DOIC in most
>>>>> cases behave like non supporting agents.
>>>>> They focus on new text you introduced. I agree that restructuring
>>>>> may require new text, however, I believe that with the new text a
>>>>> new concepts is introduced which macerates the agreed end-to-end
>>>>> concept and allows all DOIC agents on the path to do what they
>>>>> wants, so that we end up in a hop-by-hop concept.
>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop
>>>> approach of the roach draft was reason not to proceed with that draft.
>>>>
>>>>> Should read: "Reacting nodes indicate support for DOIC by including
>>>>> the OC-Supported-Features AVP into all request messages originated
>>>>> or relayed by the Reacting node."
>>>>> OC-xxx AVPs must not be included in an answer message when the
>>>>> corresponding request did not contain an OC-S-F AVP.
>>>> SRD> Agreed.
>>>>> Should read "The reporting node only includes an indication of
>>>>> support for one overload abatement algorithm.  This is the
>>>>> algorithm that the reporting node intends to use should it enter an
>>>>> overload condition or requests to use while it actually is in 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."
>>>> SRD. OK.
>>>>> the same time takes the role of a reacting node (reacting on
>>>>> reports received from an upstream reporting node)".
>>>>> separately. The content of the OC-S-F AVP sent by the agent
>>>>> upstream should reflect what the agent is able and willing to
>>>>> support (as always).
>>>> one association between C and A, and one association between A and
>>>> S. Both associations are "end-to-end" as there may be transparent
>>>> (supporting or non-supporting) agents in the middle.
>>>>> Should read: "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."
>>>> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that
>>>> contain a DiameterIdentity in the Destination-Host AVP that matches
>>>> the reporting host's DiameterIdentity"
>>>>> I don't understand. I can understand: "Reporting nodes use the
>>>>> OC-OLR AVP to communicate overload occurances towards reacting nodes."
>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement
>>>> algorithm but the reporting node that uses the OC-OLR AVP to
>>>> communicate overload occurances.
>>> Agree.
>>>
>>>>> may be misleading. A DOIC supporting agent sitting between DOIC
>>>>> supporting client and DOIC supporting Server is transparent with
>>>>> regard to DOIC. This agent does not indicate DOIC support.
>>>> SRD> I disagree.
>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear.
>>>> Should be: ...This agent does not indicate its DOIC support, rather
>>>> it transparently forwards the client's DOIC support.
>>>>> Should read:"If a request message handled by the DOIC agent does
>>>>> not include the OC-Supported-Features AVP then the DOIC agent
>>>>> inserts the AVP."
>>>>> Should read "If the message already has the AVP then the agent
>>>>> either leaves it unchanged in the relayed message or replaces it to
>>>>> reflect the features the agent is able and willing to support."
>>>>> Clarification is needed to say that strict rules must be followed
>>>>> by the agent to select the correct option. These rules take into
>>>>> account whether the request is host-routed or relam-routed and
>>>>> whether the agent is configured to select the server for
>>>>> realm-routed requests.
>>>>> Should read: "Based on the content of the OC-Supported-Features AVP
>>>>> in the request message, the reporting node knows what overload
>>>>> control functionality is supported by the reacting node.  The
>>>>> reporting node then acts accordingly for the subsequent answer
>>>>> messages it initiates for the transaction."
>>>> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing
>>>> two sentences? The proposal is to insert "is" between
>>>> "functionality" and "supported", to add "the" between "by" and
>>>> "reacting", to replace "node(s)" with "node", and to insert "for the
>>>> transaction" after "initiates".
>>>>> Should read: "Lack of the OC-Supported-Features AVP in the request
>>>>> message indicates that there is no downstream reacting node for the
>>>>> transaction."
>>>> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not
>>>> correct. It should either read: "Lack of the OC-Supported-Feature
>>>> AVP in the request message indicates to the reporting node that
>>>> there is no reacting node for the transaction" or as proposed above.
>>>>> Should read: "An agent MAY replace the OC-Supported-Features AVP
>>>>> carried in answer messages." This replacement must follow general
>>>>> rules. Its not so that the agent may do what ever it wants to. The
>>>>> decision must be based on whether or not the agent has replaced the
>>>>> OC-S-F in the corresponding request.
>>>> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with
>>>> identical values. You remove what has been received in and insert
>>>> your own stuff.
>>> Agent (proxy) can always do that i.e. modify the APV contents.
>>> Obviously if an agent tampers the OC-Supported-Features AVP it needs
>>> to know what it is doing. In general agree with the clarification but
>>> not with the proposed text.
>>>
>>> - Jouni
>>>
>>>>> Should read: "A reporting node using the loss algorithm must use
>>>>> the OC-Reduction-Percentage AVP (Section 6.7) to indicated the
>>>>> desired percentage of traffic reduction."
>>>> SRD> Agreed.
>>>>> Should read: "Editor's note: The above duplicates what is in the
>>>>> OC-Reduction-Percentage AVP section and can probably be removed."
>>>>> Should read: "If the reacting node does not receive a an OLR in the
>>>>> answer that corresponds to the probe request messages sent to the
>>>>> formally overloaded node then the reacting node should slowly
>>>>> increase the rate of traffic sent to the overloaded node."

---

From: Steve Donovan <[email-masked]>
Date: Mon, 21 Jul 2014 12:44:41 -0400

On 7/21/14, 10:53 AM, Jouni Korhonen wrote:
> Why? If you have a hierarchy of agents I don't see a reason why some 
> of those could be just "vanilla agents" or DOIC agents with 
> functionality turned off. Not arguing such deployment makes sense but 
> the protocol solution should be able to cope with that.
SRD> I agree that some of the agents can have DOIC behavior turned off, 
as long as the agent in question does not have a direct transport 
connection to a Diameter node that could generate a host report.
>>>>> node,
>>>>> There is
>>>>> can
>>>>> about
>>>>>> should be based on requiements set by the (future) specification 
>>>>>> that
>>>>>> introduces other DOIC features
>>>>> all,

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 21 Jul 2014 20:44:40 +0300

Steve,

A bit more inline.

> connection to a Diameter node that could generate a host report.

Ok. One more thing. If there is an agent that either has no DOIC 
capability or it is turned off the outcome can be 
non-optimal/non-desired, but that should not break anything, right? In 
that light I do not understand the direct peer connection requirement 
since if the agent allows turning off the DOIC functionally such 
deployment can be done irrespective what the RFC says (e.g. 
misconfiguration or for a specific reason).

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Mon, 21 Jul 2014 14:17:01 -0400

Inline...
> misconfiguration or for a specific reason).
Things don't work if the Diameter nodes that have direct transport 
connections to overloaded servers do not support DOIC.  We illustrated 
that use case in the draft in the section about non supporting agents 
with the statement that that specific deployment scenario should be avoided.

If an operator wants to deploy a network that doesn't not properly 
handle overload then they are free to do so.  We cannot prevent that 
from happening.  We do need to have a mechanism that does allow sane 
operators to deploy their network in a way that properly handles 
overload.  This requires us to recognize that agents will be required to 
react to overload reports.

Do you disagree with this?
>>>>>>> not
>>>>>>>> I cannot understand this sentence. Probably only simple typos 
>>>>>>>> but I
>>>>>>>> don't know.
>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 
>>>>>>> 18,
>>>>>>> and 19.
>>>>>>>      I agree to the change.
>>>>>>>>> A New Internet-Draft is available from the on-line 
>>>>>>>>> Internet-Drafts
>>>>>>>>> directories.

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 21 Jul 2014 22:01:58 +0300

Steve,

Inline.

> connections to overloaded servers do not support DOIC.  We illustrated

Obviously.

> with the statement that that specific deployment scenario should be

Should be avoided is fine.

> from happening.  We do need to have a mechanism that does allow sane

Exactly.. and operators might have a reason to do so e.g. for temporarily.

> Do you disagree with this?

I agree but I want to be clear on the wording with MUSTs and alike that 
the specification does not imply that all proxies must be upgraded for 
DOIC to work or that the operator cannot have a local policy that 
applies DOIC selectively.

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Mon, 21 Jul 2014 17:13:55 -0400

Jouni,

One more (hopefully) inline...

On 7/21/14, 3:01 PM, Jouni Korhonen wrote:
> I agree but I want to be clear on the wording with MUSTs and alike 
> that the specification does not imply that all proxies must be 
> upgraded for DOIC to work or that the operator cannot have a local 
> policy that applies DOIC selectively.
I'm assuming (or hoping) you mean agent, not proxy.  The same can be 
said about clients and servers.  Operators can turn DOIC on and off for 
the same reasons they would do it for agents.  I'm not sure how this 
gets reflected in the text of a protocol specification, but I suspect we 
can come up with agreeable wording.
>>>>>>>>>> This should be left to the (future) specification that 
>>>>>>>>>> introduces
>>>>>>>>>> other DOIC features.
>>>>>>>>>>
>>>>>>>>>>>         This specification documents a Diameter Overload 
>>>>>>>>>>> Control
>>>>>>>>>>> (DOC) base

---

From: Ben Campbell <[email-masked]>
Date: Mon, 21 Jul 2014 17:50:00 -0400

On Jul 21, 2014, at 2:17 PM, Steve Donovan <[email-masked]> wrote:

>> Ok. One more thing. If there is an agent that either has no DOIC capability or it is turned off the outcome can be non-optimal/non-desired, but that should not break anything, right? In that light I do not understand the direct peer connection requirement since if the agent allows turning off the DOIC functionally such deployment can be done irrespective what the RFC says (e.g. misconfiguration or for a specific reason).
> Things don't work if the Diameter nodes that have direct transport connections to overloaded servers do not support DOIC. We illustrated that use case in the draft in the section about non supporting agents with the statement that that specific deployment scenario should be avoided.
> 

One thing we should keep in mind is that we cannot really assume that only one node, or "tier" of nodes has a direct connection to servers. e.g:

             S
           /      
C----A1    S 
   \       \   /
     S      A2
               \
                S

Is a perfectly legal, if weird, configuration.

And to further complicate things, consider that A2 might perform topology hiding, so that A1 thinks it's a server.

> If an operator wants to deploy a network that doesn't not properly handle overload then they are free to do so.  We cannot prevent that from happening.  We do need to have a mechanism that does allow sane operators to deploy their network in a way that properly handles overload.  This requires us to recognize that agents will be required to react to overload reports.
>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 21 Jul 2014 18:06:40 -0400

> And to further complicate things, consider that A2 might perform topology hiding, so that A1 thinks it's a server.

We should also not forget the possibility of servers sending requests to clients. A slightly different picture:

C                 S
   \              /
C--A1 -- A2    
   /              \
C                 S

If a server sends a realm-routed request to a client (not common, but not illegal), A1 becomes the "server-selecting node".

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Wed, 23 Jul 2014 04:12:15 +0000

Hello all,

Please see some views from my side.

Best Regards,
Susan

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Monday, July 21, 2014 2:56 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; [email-masked]
Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt

Some comments inline..

> informative text is not accurate, then these things need to be corrected.

Susan: I support Ulrich's view. In my understanding, the assumption we agreed for this basic mechanism is to define an end-to-end approach, not a hop-by-hop one. I don't see the reason to come back again to this discussion at this stage.

Susan: Same, agree with Ulrich. Agents may only be non-transparent in case the agent supports DOIC, and the server or client does not support DOIC or in case the agent which supports DOIC itself overloads, which is to be addressed in another draft. For the basic case, I don't see the need for the agent to do anything related to DOIC if both server and client support DOIC.

OK to do the change.

Agree.

Susan: Agree with Ulrich.

Susan: Modify is fine. If it is with identical values, the agent can leave it unchanged even the agent is going to do something.

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Thu, 24 Jul 2014 14:17:30 -0400

On Jul 20, 2014, at 8:24 PM, Jouni Korhonen <[email-masked]> wrote:

> Agree that "transparent" is a bit bad wording here, because for me at least "transparent proxies" have a strong existing behavioral model (from HTTP proxies that is..).
> 
> For me the DOIC agent behaviour should be the following (by local configuration etc):
> 

For specification purposes, I think we can consider a DOIC node with DOIC turned off to be the same thing as a non-supporting node. We don't care if they _can_ support DOIC, only if they _do_.

>   be e.g. behaving as an endpoint for non-supporting nodes.

I think it's important an agent (including a relay) is allowed to do this. I gather from the thread so far that some think it should not be allowed to do so.

>   and Diameter level). Otherwise the same as 2)

This is an interesting case. As others have noted, there is no externally visible difference (on a given transaction) between a DOIC-supporting agent that forwards OC-S-F unchanged, and an non-supporting agent. That brings up an important question that we discussed a little bit in the working group meeting: Do we need the ability to tell if a peer agent supports DOIC?

I _think_ we do. I think the same arguments we used on whether a client or server being able to tell if the server or client supported DOIC apply here. Peer nodes need to be able to apply local policy in ways that may be different depending on whether the immediate peer (including a peer which is an agent)  supports DOIC or not.

For an example (a simplified version of the use case I showed in the wg meeting), consider that an operator only wants to send OLRs to nodes that are authorized to receive it. It might trust a DOIC-supporting agent to enforce that policy, but not trust a non-supporting agent to do it. In the former case, it includes the OLR, in the later case, it does not. But it can't make that distinction without knowledge of whether the agent supports DOIC.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 24 Jul 2014 14:22:32 -0400

> Susan: I support Ulrich's view. In my understanding, the assumption we agreed for this basic mechanism is to define an end-to-end approach, not a hop-by-hop one. I don't see the reason to come back…

I don't recall any consensus in the DIME working group that DOIC was limited to end-to-end reporting of overload. I agree that it should be _possible_ to report overload end-to-end, but also possible to do otherwise.

It's entirely reasonable that 3GPP could then agree to limit some applications to using DOIC end-to-end. But we should be careful not to build that limitation into the mechanism in the IETF.

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Thu, 24 Jul 2014 18:33:31 +0000

Even I thought that we agreed end-to-end approach as compared to hop-by-hop approach at the beginning of working on this draft. 
In that context the endpoints are the reacting and reporting node between which Overload association is established. 

So I am also bit puzzled that we are talking about the possibility of hop-by-hop approach as part of this draft.

Regards,
Nirav.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 24 Jul 2014 14:49:51 -0400

> So I am also bit puzzled that we are talking about the possibility of hop-by-hop approach as part of this draft.

I am also a bit puzzled. DOIC endpoints were never assumed to only be DIameter clients and servers. This was true even of the picture Jouni drew on the board in Porto. I have never supported a solution that only allowed end-to-end reporting where the "ends" could only be Diameter clients and servers. Such a solution would preclude a _lot_ of real world use cases.

Is it possible we are getting wrapped around terminology of what constitutes a DOIC endpoint? I am okay with an end-to-end approach between DOIC endpoints, as long as an agent can be a DOIC endpoint.  (But really, we are getting into the realm of philosophy here.)

---

From: Steve Donovan <[email-masked]>
Date: Thu, 24 Jul 2014 15:55:11 -0400

I believe that the job we have here is to define a set of AVPs and 
behaviors associated with those AVPs that will allow operators to manage 
overload in their Diameter networks.

I'm not sure where the assumption that moving away from the Roach draft 
meant there could be no hop-by-hop aspects to the solution.

I do think this whole conversation is a red herring, meaning that it is 
not adding to completing the DOIC solution.

We don't have a hop-by-hop solution in what is in the DOIC draft today.  
We also do not have an pure end-to-end solution.  We have a solution 
where Diameter Clients, Diameter Agents and Diameter Servers do DOIC 
things.  What DOIC things they do depends on the specific scenario.

The most basic case that involves agents requires all three types of 
Diameter nodes to do DOIC things when a server sends a host report. This 
is shown in the first use case in the agent cases draft.  Does the fact 
that both the client and the agent are reacting nodes make this a 
hop-by-hop solution?  Does it matter?

My plan over the next few weeks is to propose detailed text to close the 
current open issues.  I suggest that we keep our focus on whether that 
text addresses our agreed to requirements.  I also remind everyone that 
we are trying very hard to have this draft ready for IETF working group 
last call prior to the November IETF meeting.  We will need to be 
aggressive in agreeing to text and closing those issues.

To say it another way, let's move on from the hop-by-hop/end-to-end 
discussion.

Regards,

Steve

---

From: Ben Campbell <[email-masked]>
Date: Thu, 24 Jul 2014 18:24:12 -0400

I mostly agree. In fact, I may over-agree, in that I think that people have it in their minds to say too much, especially in regards to agents. Almost none of this discussion should result in normative language. Basically, I think we should allow pretty much any agent behavior that doesn't break things*, and leave it to the market (and client SDOs) to decide what's important.

(* Where I define "break things" to mean "making things worse than if the agent did not support DOIC at all".)

More inline:

On Jul 24, 2014, at 3:55 PM, Steve Donovan <[email-masked]> wrote:

> I believe that the job we have here is to define a set of AVPs and behaviors associated with those AVPs that will allow operators to manage overload in their Diameter networks.
> 
> I'm not sure where the assumption that moving away from the Roach draft meant there could be no hop-by-hop aspects to the solution.
> 
> I do think this whole conversation is a red herring, meaning that it is not adding to completing the DOIC solution.
> 
> We don't have a hop-by-hop solution in what is in the DOIC draft today.  We also do not have an pure end-to-end solution.  We have a solution where Diameter Clients, Diameter Agents and Diameter Servers do DOIC things.  What DOIC things they do depends on the specific scenario.

I concur, but would go on to say "depends on the specific scenario, network configuration, and local policy."

> 
> The most basic case that involves agents requires all three types of Diameter nodes to do DOIC things when a server sends a host report.

I disagree that it _requires_ it. I agree that you get better behavior if you do it, and deployments should be allowed to operate that way. But if people want to build networks where the agent doesn't do anything most of the time, they should also be able to do so. For example, they might have so few realm-routed requests that the extra complexity is not worth it.  (I'm ignoring the question about whether such an agent supports DOIC at all--let's pretend for the sake of argument it at least occasionally does something DOICish.)

> This is shown in the first use case in the agent cases draft.  Does the fact that both the client and the agent are reacting nodes make this a hop-by-hop solution?

Not at all, but again with the caveat that this is _one_ way of doing it.

>  Does it matter?

No.

> 
> My plan over the next few weeks is to propose detailed text to close the current open issues.  I suggest that we keep our focus on whether that text addresses our agreed to requirements.  I also remind everyone that we are trying very hard to have this draft ready for IETF working group last call prior to the November IETF meeting.  We will need to be aggressive in agreeing to text and closing those issues.
> 
> To say it another way, let's move on from the hop-by-hop/end-to-end discussion.

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Fri, 25 Jul 2014 04:21:41 +0000

Ben,

Are you reading too much between the lines since I never mentioned "client" or "server" in my e-mail below.

End-to-end approach can become hope-by-hop depending upon the network topology and which nodes are acting as reporting and reacting nodes. But it is still not "hop-by-hop" approach since in that case the overload control is strictly performed between the nodes sharing the transport connection.

Regards,
Nirav.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 25 Jul 2014 00:55:57 -0400

> On Jul 25, 2014, at 12:21 AM, "Nirav Salot (nsalot)" <[email-masked]> wrote:
> 
> Ben,
> 

This appears to be true, and I agree with that characterization. 

 Apologies for the confusion. I was reacting to comments from further down the thread that I took to mean people only wanted to allow DOIC to operate between client and server, except for some strictly limited circumstances. I may have misread those as well.

Thanks,

Ben.

---

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

Steve,

I can agree with most of your statements.

A DOICable agent needs to determine in which scenario it actually is. This decision must be based on presence/absence of OC-S-F-AVP in the received requests, presence/absence of Destination-Host AVP in the received request and configuration data (configured to select/not to select the server for realm routed requests).

Once this decision is taken the  agent
a) inserts an OC-S-F to the request, or
b) transparently forwards the request (i.e. does not remove or add an OC-S-F AVP), or
c) removes the received OC-S-F AVP and inserts its own OC-S-F AVP

note that c) includes the case where the removed AVP and the inserted AVP are identical.

Case b) is the transparent case where the agent - although it supports DOIC (and DOIC is not turned off) - from an external point of view behaves like a non-DOICable node.

See also inline.

Regards,
Ulrich
(still trying to catch up with lots of mails)

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Monday, July 21, 2014 4:29 PM
To: [email-masked]
Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt)

Ulrich,

<Ulrich>I agree</Ulrich>

<Ulrich>yes</Ulrich>

Does transparent mean that there is no observable difference in the DOIC 
AVPs that pass through the agent
<Ulrich>yes</Ulrich> or does it mean that there is no 
observable difference in how transactions are handled by the DOIC agent?
<Ulrich>no</Ulrich>

"DOIC nodes with a direct transport connection to a reporting node that 
has an active overload report must handle abatement of realm-routed 
requests.  The preferred method for handling abatement of realm-routed 
requests is diversion, where the node with the direct transport 
connection routes the request to an alternative server that is able to 
handle the request.  If there is no alternative server with the needed 
capacity to handle the request then the DOIC node must/should throttle 
the necessary requests to meet the requested reduction in traffic."
<Ulrich> My proposal:
"A DOIC node with performs server selection for realm routed requests that 
has active overload reports from servers it potentially selects, must
handle abatement of realm-routed 
requests.  The preferred method for handling abatement of realm-routed 
requests is diversion, where the node selecting the server routes the
request to an alternative server that is able to 
handle the request.  If there is no alternative server with the needed 
capacity to handle the request then the DOIC node must/should preferrably
delegate abatement (of realm routed requests) towards a downstream reacting
node or otherwise throttle 
the necessary requests to meet the requested reduction in traffic."
</Ulrich>

Regards,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Tue, 29 Jul 2014 09:05:37 -0500

Ulrich,

Thanks for the detailed response.  I think we are very close to being in 
agreement.

The area I'm not sure about yet is using the wording "A DOIC node that 
does server selection" versus "A DOIC node with a direct transport 
connection".

A client might think it is doing server selection even when it is 
connecting to an agent.  That is why I used the "direct transport 
connection" wording to make it more explicit.

What is the objection to this wording?

This could also be solved by adding a definition of server selection, 
but it would need to be done in a way that also addresses transactions 
that flow from a Diameter server to a Diameter client.

Regards.

Steve

---

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

Steve,

It is my understanding that the node (client or agent) which performs server selection (e.g. selects server S) needs to make sure that any upstream agent will not undo the selection (e.g. by selecting another server Z). This can be ensured by inserting a Destination-Host AVP containing S's DiameterIdentity to the request. Inserting the Destinatio-Host AVP is not needed when there are no upstream agents i.e. when there is a "direct transport connection" to the selected server. The case where the node that selects the server for a realm-routed request has a direct transport connection to the selected server is not the general case.  

A DOICable node (client or agent) may face the situation where it has to send out a realm-routed request. Before sending the request it may detect that it (the node) is configured to perform server selection. The node selects server S. Now (still before sending the request out) the node detects (from checking overload states) that S is overloaded therefore it performs abatement (diversion to Z). Now the node may either have a direct transport connection to Z in which case it sends the request to Z (this is the case you covered), or it does not have a direct transport connetion to Z in which case it inserts the Destination-Host AVP with Z's Diameter Identity and sends the request to the next hop.

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:[email-masked]] 
Sent: Tuesday, July 29, 2014 4:06 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt)

Ulrich,

Regards.

Steve

---

From: Steve Donovan <[email-masked]>
Date: Tue, 29 Jul 2014 11:51:27 -0500

Ulrich,

Thanks for the clarification.  I agree, if the DOIC node that does 
server selection on a realm-routed request includes the destination-host 
after selecting the server then I'm good with your wording, modulo some 
cleanup.

After we've seen if anyone objects to the wording, I'll come back with a 
detailed proposal for where the wording should go into the -04 version.

Steve

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 30 Jul 2014 15:01:09 +0300

Few comments inline..

> A DOICable node (client or agent) may face the situation where it has to send out a realm-routed request. Before sending the request it may detect that it (the node) is configured to perform server…

I have a problem with this. My understanding is that the server 
selection does not imply intermediate nodes inserting Destination-Host 
into the request independent there is direct transport connection or 
not.. Or am I reading the intention of this paragraph wrong? Up to the 
point the realm routed (Destination-Realm only case) request reaches the 
"server" it is pure routing & forwarding of the request. The insertion 
of the Destination-Host is done by the client when it has learned the 
used server (from the Origin-Host). If the client has the desination 
host information already it may or may not insert Destination-Host into 
request.. depending of its needs.

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 30 Jul 2014 13:07:30 +0000

Jouni,

this may be true for server selecting nodes that do not support DOIC.

However, when the server selecting node supports DOIC, once the server is selected and the abatement (according to a previously received OLR from the selected server) is performed (e.g. a 30% throttling was survived), you do not want upstream agents to undo the server selection (as it cannot undo the throttling that is associated with the originaly selected server). 
Therefore I think we should mandate that DOIC supporting nodes that perform server selection and perform abatement according to reports received from the selected server make sure that upstream agents do not select another server. Otherwise we end up with a mismatch between performed abatement and eventually selected server.

Ulrich 

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Wednesday, July 30, 2014 2:01 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; [email-masked]
Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt)

Few comments inline..

- Jouni

---

From: Jouni <[email-masked]>
Date: Wed, 30 Jul 2014 16:36:29 +0300

Ulrich,

I have no problem with DOICable node doing routing/forwarding based on load whatever. But I have an issue an intermediate node adding Destination-Host into a request when the client did not originally insert one. I am a bit cautious that an agent next to a server can be overruled by other agents when selecting the server. While this all is still within RFC6733 boundaries it is somewhat different than in RFC6733. That's why I have concerns with this. 

Jouni

-- 
Jouni Korhonen
Broadcom

(Sent from my mobile..)

> "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]> kirjoitti 30.7.2014 kello 16.07:
> 
> Jouni,
>

---

From: <[email-masked]>
Date: Wed, 30 Jul 2014 13:46:28 +0000

Hi,

IMHO, node selection is performed when multiple servers are present in the realm-routing table for a given realm entry. And if multiple servers are present in table, it is because multiple connections are available. In fine, it is the connection that is selected. No need for an agent to insert the Dest-Host AVP in the request. Therefore, I agree that DOICable may/must use the overload reports received from the different servers to select the most suitable server, but I agree with Jouni that an agent does not have to insert Dest-Host AVP.

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Jouni
Envoyé : mercredi 30 juillet 2014 15:36
À : Wiehe, Ulrich (NSN - DE/Munich)
Cc : [email-masked]
Objet : Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt)

Ulrich,

Jouni

-- 
Jouni Korhonen
Broadcom

(Sent from my mobile..)

---

From: Steve Donovan <[email-masked]>
Date: Wed, 30 Jul 2014 09:00:52 -0500

The question is the behavior of a DOIC node that does abatement of 
"realm-route-requests" in the face of a host report for a server.

I think the DOIC specification needs to say that for a DOIC node to do 
abatement of realm-routed-requests it needs to be able to guarantee that 
the request that survive abatement will be routed to the reporting node 
for the host report.  This is easy to achieve if the DOIC node has a 
direct transport connection to the reporting node.  Ulrich's point is 
that it can also be achieved by the DOIC node inserting destination-host 
for requests targeted for the reporting node that survive abatement.

Steve

---

From: Dave Dolson <[email-masked]>
Date: Wed, 30 Jul 2014 14:33:38 +0000

Host overload reports should not affect realm-route-requests.
The system will be more stable if the two control systems are independent, not cross-coupled.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Wednesday, July 30, 2014 10:01 AM
To: [email-masked]
Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt)

Steve

---

From: <[email-masked]>
Date: Wed, 30 Jul 2014 14:48:18 +0000

I was commenting Ulrich's point on the insertion of the Dest-Host. My answer was based on the RFC6733. The Dest-Host is inserting by the node initiating the request. Anything relating to a an agent inserting a Dest-Host on behalf of the request initiator should be left out of the specification.

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : mercredi 30 juillet 2014 16:01
À : [email-masked]
Objet : Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt)

Steve

---

From: Steve Donovan <[email-masked]>
Date: Wed, 30 Jul 2014 09:55:53 -0500

I'm ok with keeping it limited to just DOIC nodes that have direct 
transport connections.  I agreed with Ulrich's suggestion because there 
are agents in the wild that can insert destination-Host, depending on 
local policy.

It is, however, probably better to remain consistent with RFC6733.

Steve

---

From: Steve Donovan <[email-masked]>
Date: Wed, 30 Jul 2014 10:01:05 -0500

Dave,

A host report is a request by the reporting node to reduce traffic to 
that node, regardless of the type of request.  In order to achieve that 
reduction, it is necessary to abate both "host-routed" requests and 
"realm-routed" request".  The first use case in the agent cases draft 
illustrates this scenario where the client handles abatement of the 
host-routed requests and the agent that has direct transport connection 
to the reporting node handles abatement of realm-routed requests.

There is no mechanism for the reporting node to request a reduction in 
host-routed requests separate from realm-routed requests.  One of the 
reasons is that for realm-routed requests there may be other nodes that 
could handle the request.

Steve

---

From: Dave Dolson <[email-masked]>
Date: Wed, 30 Jul 2014 16:03:10 +0000

Sorry for not paying attention...

But wouldn't it be simpler and more stable to keep them independent?

As you describe, host-routed requests need to consider host load and also realm load, 

Here is my perspective:
1- when sending a host-routed request, only the load of the destination-host matters. The overall realm load is irrelevant
2- when sending a realm-only-routed request, only the ability of the realm to accept a new session matters.

I believe we've got (2) right by saying that realm-routed abatement does not apply to messages with destination-host.

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]] 
Sent: Wednesday, July 30, 2014 11:01 AM
To: Dave Dolson; [email-masked]
Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt)

Dave,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Wed, 30 Jul 2014 11:29:33 -0500

Dave,

Please see inline.

Steve

> But wouldn't it be simpler and more stable to keep them independent?
Definitely not simpler.  This would require the reporting node, 
generally a server, to know more than just the its own overload state.  
A realm-routed request can go to multiple servers, all with different 
overload states.  To send a realm report requires knowledge of all of 
the servers in the realm.  Keeping the reports separate would also 
require an understanding of the mix of host-routed requests and 
realm-routed requests, something that is likely to be very dynamic and 
certainly will be different across applications.

The loss algorithm is designed to be very simple.  The reporting node 
requests a percentage reduction of traffic sent to it and the reacting 
node(s) abate that percentage of traffic sent to the node.
> 1- when sending a host-routed request, only the load of the destination-host matters. The overall realm load is irrelevant
Agreed, mostly.  Only the load of the reporting node matters.  This 
still requires reducing all traffic sent to the node, both host-routed 
and realm-routed requests.
> 2- when sending a realm-only-routed request, only the ability of the realm to accept a new session matters.
Not necessarily.  Realm-routed requests are used for things other than 
establishing new sessions.  There are applications that are not session 
based, for instance.  There are applications that do not require mid 
session requests to have the destination-host AVP.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 30 Jul 2014 15:42:59 -0500

While I don't think we should forbid an intermediate agent directing messages to specific servers using Destination-Host, I don't think we should suggest that it's a good idea. Assuming people see this as away around the proposed guidance to avoid having a non-DOIC agent in the "last-peer-before-server" position, it has some pretty severe limitations:

1) It only works if the intermediate server knows what servers it can choose among. (And it should probably also know current load state for them.) While you can build networks that way, you do so at the expense of flexibility and manageability.

2) There's no way to say things like "Don't send this to server A, but any other server is okay". That means the intermediate server completely owns server selection for all requests during the overload event. Even ones that don't get diverted. Otherwise, the upstream agent will redistribute those "non-diverted" requests however it wants to, and that is not likely to match what the DOIC-supporting intermediary wants to do.

3) It doesn't solve the situation where a node thinks it is selecting servers, but some or all of those servers are really topology-hiding agents, which seems like the biggest reason we would can't normatively limit diversion to directly-connected agents.

On Jul 30, 2014, at 9:00 AM, Steve Donovan <[email-masked]> wrote:

> The question is the behavior of a DOIC node that does abatement of "realm-route-requests" in the face of a host report for a server.
> 
> I think the DOIC specification needs to say that for a DOIC node to do abatement of realm-routed-requests it needs to be able to guarantee that the request that survive abatement will be routed to the reporting node for the host report.  This is easy to achieve if the DOIC node has a direct transport connection to the reporting node.  Ulrich's point is that it can also be achieved by the DOIC node inserting destination-host for requests targeted for the reporting node that survive abatement.
> 
> Steve
>

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Thu, 31 Jul 2014 06:21:54 +0000

Hello,

I support Dave's view on the host-routed request and realm-routed request. There is no need for the reacting node to mix two reports, since host-routed request cannot be routed to other servers. Realm-routed overload report is only useful for the message without specific Destination-Host present.

Best Regards,
Susan

-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Thursday, July 31, 2014 12:03 AM
To: Steve Donovan; [email-masked]
Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt)

Here is my perspective:

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]]
Sent: Wednesday, July 30, 2014 11:01 AM
To: Dave Dolson; [email-masked]
Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt)

Dave,

A host report is a request by the reporting node to reduce traffic to that node, regardless of the type of request.  In order to achieve that reduction, it is necessary to abate both "host-routed" requests and "realm-routed" request".  The first use case in the agent cases draft illustrates this scenario where the client handles abatement of the host-routed requests and the agent that has direct transport connection to the reporting node handles abatement of realm-routed requests.

There is no mechanism for the reporting node to request a reduction in host-routed requests separate from realm-routed requests.  One of the reasons is that for realm-routed requests there may be other nodes that could handle the request.

Steve

On 7/30/14, 9:33 AM, Dave Dolson wrote:
> abatement of realm-routed-requests it needs to be able to guarantee 
> that the request that survive abatement will be routed to the 
> reporting node for the host report.  This is easy to achieve if the 
> DOIC node has a direct transport connection to the reporting node.  
> Ulrich's point is that it can also be achieved by the DOIC node 
> inserting destination-host for requests targeted for the reporting node that survive abatement.
>
> Steve
>
>> De : DiME [mailto:[email-masked]] De la part de Jouni Envoyé : 
>> mercredi 30 juillet 2014 15:36 À : Wiehe, Ulrich (NSN - DE/Munich) Cc 
>> : [email-masked] Objet : Re: [Dime] Transparent agents (was Re: I-D 
>> Action: draft-ietf-dime-ovli-03.txt)
>>
>> Ulrich,
>>

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Thu, 31 Jul 2014 06:33:06 +0000

Hello Dave,

My view is that the server only cares about its own overload state, there is no need for a server to know the overload status of the realm, which should be the responsibility of the agent serving a server farm.

If the reacting node is unable to know the destination-host of the request, the request will be treated as realm-routed messages and realm-routed report will be applied, whatever the request is session related or not, first message or mid-session request.

Best Regards,
Susan

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]] 
Sent: Thursday, July 31, 2014 12:30 AM
To: Dave Dolson; [email-masked]
Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt)

Dave,

Please see inline.

Steve

> But wouldn't it be simpler and more stable to keep them independent?
Definitely not simpler.  This would require the reporting node, generally a server, to know more than just the its own overload state.  
A realm-routed request can go to multiple servers, all with different overload states.  To send a realm report requires knowledge of all of the servers in the realm.  Keeping the reports separate would also require an understanding of the mix of host-routed requests and realm-routed requests, something that is likely to be very dynamic and certainly will be different across applications.

The loss algorithm is designed to be very simple.  The reporting node requests a percentage reduction of traffic sent to it and the reacting
node(s) abate that percentage of traffic sent to the node.
> 1- when sending a host-routed request, only the load of the 
> destination-host matters. The overall realm load is irrelevant
Agreed, mostly.  Only the load of the reporting node matters.  This still requires reducing all traffic sent to the node, both host-routed and realm-routed requests.
> 2- when sending a realm-only-routed request, only the ability of the realm to accept a new session matters.
Not necessarily.  Realm-routed requests are used for things other than establishing new sessions.  There are applications that are not session based, for instance.  There are applications that do not require mid session requests to have the destination-host AVP.

> that node, regardless of the type of request.  In order to achieve 
> that reduction, it is necessary to abate both "host-routed" requests 
> and "realm-routed" request".  The first use case in the agent cases 
> draft illustrates this scenario where the client handles abatement of 
> the host-routed requests and the agent that has direct transport 
> connection to the reporting node handles abatement of realm-routed requests.
>
> reasons is that for realm-routed requests there may be other nodes 
> that could handle the request.
>
> Steve
>
>> I think the DOIC specification needs to say that for a DOIC node to 
>> do abatement of realm-routed-requests it needs to be able to 
>> guarantee that the request that survive abatement will be routed to 
>> the reporting node for the host report.  This is easy to achieve if 
>> the DOIC node has a direct transport connection to the reporting 
>> node.  Ulrich's point is that it can also be achieved by the DOIC 
>> node inserting destination-host for requests targeted for the reporting node that survive abatement.
>>
>> Steve
>>
>>> De : DiME [mailto:[email-masked]] De la part de Jouni Envoyé 
>>> : mercredi 30 juillet 2014 15:36 À : Wiehe, Ulrich (NSN - DE/Munich) 
>>> Cc : [email-masked] Objet : Re: [Dime] Transparent agents (was Re: 
>>> I-D Action: draft-ietf-dime-ovli-03.txt)
>>>
>>> Ulrich,
>>>

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 31 Jul 2014 10:10:37 +0300

> IMHO, node selection is performed when multiple servers are present in the realm-routing table for a given realm entry. And if multiple servers are present in table, it is because multiple connecti…

Exactly what I meant.

- Jouni

---

From: Dave Dolson <[email-masked]>
Date: Thu, 31 Jul 2014 12:52:53 +0000

That makes sense to me. When I was talking about new sessions, I was thinking about stateful session-oriented protocols that use realm-only-routed requests only at the start of the session. I understand that other protocols may be different.

I think it is conceivable that realm overload state could be known by the individual hosts or by a load-balancing agent serving them; a vendor could provide either solution when the vendor provides the load-balancing agent.

Is it intended to standardize the algorithm a load-balancing agent would use to calculate and insert realm overload report by aggregating host overload reports?  Or would be up to the vendor?

I guess this would be in section 4.2.4.

-----Original Message-----
From: Shishufeng (Susan) [mailto:[email-masked]] 
Sent: Thursday, July 31, 2014 2:33 AM
To: Steve Donovan; Dave Dolson; [email-masked]
Subject: RE: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt)

Hello Dave,

Best Regards,
Susan

-----Original Message-----
From: Steve Donovan [mailto:[email-masked]] 
Sent: Thursday, July 31, 2014 12:30 AM
To: Dave Dolson; [email-masked]
Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt)

Dave,

Please see inline.

Steve