Subject: [Dime] DOIC endpoint behavior - Agent Overload Report handling

From: Steve Donovan <[email-masked]>
Date: Tue, 04 Feb 2014 07:29:06 -0600

The following wording is proposed to be added to section 5.5 on Overload
Report Processing.

This goes along with the proposed wording for agent involvement in
capability exchange.

The most important piece of behavior proposed is for the case when the
agent is a back-to-back DOIC association agent as illustrated here:

  DOC node <--downstream DOIC association--> DOC agent <--upstream DOIC
association--> DOC  node

In this case, it is proposed that when the DOC agent receives a host or
realm overload report the DOC agent simply passes it on without taking
further action.  The goal being to do the overload abatement as close to
the source of the request as possible.

The text isn't perfect yet, but I wanted to get the basic behavior
proposal across.

Regards,

Steve

5.5.4 Agent Considerations

As discussed in section x.x.x, agents can take on the role of reporting
node and reacting node.

Agent as reporting node

A DOC agent will take on the role of a reporting node any time that
there is a downstream DOIC association.

For the report types supporting in this document, an agent should only
originate an overload report in two cases:

- When the agent is acting as overload authority for a set of servers. 
In this case, requests are sent to the destination-host of the agent and
the agent is responsible for reporting on the overload state when the
server farm represented by that destination-host value is entering an
overloaded condition.

- When the agent is acting as overload authority for a realm.  In this
case, the agent is responsible for inserting realm based overload
reports into answer messages from servers in that realm.

Agent as reacting node

An agent will take on the role of a reacting node whenever there is an
upstream DOIC association.  In this case, the agent will be reacting to
host overload reports.

The behavior of the agent acting as a reacting node depends on whether
or not there is a downstream association.

If there is a downstream DOIC association then the DOC agent should pass
any overload report on to the downstream Diameter node without taking
any further action.

  Note: This is based on the assumption that it is best to handle the
overload instance as close to the source of the Diameter transaction as
possible.

  Note: This is not a must because there could be operator specific
policies that result in handling of the overload condition in the agent.

If there is no downstream DOIC association then the DOC agent is
responsible for handling the overload condition.  In this case the DOC
agent must throttle requests targeted for the host or realm indicated in
the overload report.  The method used should be consistent with the
considerations outlined in section 5.5.2.

When a request message is selected for throttling, the DOC agent must
generate the appropriate error response message.

Editors note: the error message to be sent is TBD.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 4 Feb 2014 14:55:40 +0000

Steve,
my understanding is different.

How would it be possible that the DOC agent that has both upstream and downstream DOIC associations receives a realm overload report?
A host overload report received by the DOC agent on the DOC agent's upstream DOIC association will be consistent with the supported features  advertised by the DOC agent on the DOC agent's upstream DOIC association but it will not necessarily be consistent with the supported features adverised by the DOC node on the DOC agent's downstream DOIC association. Actually there may not be a single supported feature in common to both associations. Therefore it makes no sense to simply pass the OLR across associations. The DOC agent should rather aggregate all received OLRs on all its upstream associations and transform the aggregation into a format the downstream DOC node understands (i.e. consistent with the supported features advertised on the DOC agent's downstream DOIC association).

Regards
Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Tuesday, February 04, 2014 2:29 PM
To: [email-masked]
Subject: [Dime] DOIC endpoint behavior - Agent Overload Report handling

The following wording is proposed to be added to section 5.5 on Overload Report Processing.

This goes along with the proposed wording for agent involvement in capability exchange.

The most important piece of behavior proposed is for the case when the agent is a back-to-back DOIC association agent as illustrated here:

  DOC node <--downstream DOIC association--> DOC agent <--upstream DOIC association--> DOC  node

In this case, it is proposed that when the DOC agent receives a host or realm overload report the DOC agent simply passes it on without taking further action.  The goal being to do the overload abatement as close to the source of the request as possible.

The text isn't perfect yet, but I wanted to get the basic behavior proposal across.

Regards,

Steve

As discussed in section x.x.x, agents can take on the role of reporting node and reacting node.

Agent as reporting node

A DOC agent will take on the role of a reporting node any time that there is a downstream DOIC association.

For the report types supporting in this document, an agent should only originate an overload report in two cases:

- When the agent is acting as overload authority for a set of servers.  In this case, requests are sent to the destination-host of the agent and the agent is responsible for reporting on the overload state when the server farm represented by that destination-host value is entering an overloaded condition. <Ulrich> In this case the overload report generated by the agent is of host-type </Ulrich>

- When the agent is acting as overload authority for a realm.  In this case, the agent is responsible for inserting realm based overload reports into answer messages from servers in that realm.

<Ulrich> In both cases the agent MUST remove OC-OLR AVPs from answer messages received from servers of the server farm / servers in the realm.</Ulrich>

Agent as reacting node

An agent will take on the role of a reacting node whenever there is an upstream DOIC association.  In this case, the agent will be reacting to host overload reports.

The behavior of the agent acting as a reacting node depends on whether or not there is a downstream association.

If there is a downstream DOIC association then the DOC agent should pass any overload report on to the downstream Diameter node without taking any further action.

  Note: This is based on the assumption that it is best to handle the overload instance as close to the source of the Diameter transaction as possible.

  Note: This is not a must because there could be operator specific policies that result in handling of the overload condition in the agent.

If there is no downstream DOIC association then the DOC agent is responsible for handling the overload condition.  In this case the DOC agent must throttle requests targeted for the host or realm indicated in the overload report.  The method used should be consistent with the considerations outlined in section 5.5.2.

When a request message is selected for throttling, the DOC agent must generate the appropriate error response message.

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 7 Feb 2014 11:45:08 +0200

Comments inline:

On Feb 4, 2014, at 3:29 PM, Steve Donovan <[email-masked]> wrote:

> - When the agent is acting as overload authority for a set of servers.  In this case, requests are sent to the destination-host of the agent and the agent is responsible for reporting on the overload state when the server farm represented by that destination-host value is entering an overloaded condition.

Makes sense and is inline what I originally thought.

> - When the agent is acting as overload authority for a realm.  In this case, the agent is responsible for inserting realm based overload reports into answer messages from servers in that realm.

Ok.

>   Note: This is not a must because there could be operator specific policies that result in handling of the overload condition in the agent.

I kind of agree Ulrich's concern here. If the two
associations have different supported features some
modifications may be needed on the OLRs. However, I
also think the "the DOC agent should pass any" is
enough to cover the case Ulrich points at, assuming
we note the case where downstream and upstream
associations have different capabilities.

> If there is no downstream DOIC association then the DOC agent is responsible for handling the overload condition.  In this case the DOC agent must throttle requests targeted for the host or realm i…

Ok.

- Jouni

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Steve Donovan <[email-masked]>
Date: Mon, 10 Feb 2014 11:10:52 -0600

This is part of the need for a definition of endpoints.  I will wait to
reply until we have resolved that question.

Steve