Subject: [Dime] PEER Report with RATE algorithm (Agent Overload + Rate Algorithm drafts)

From: Maria Cruz Bartolome <[email-masked]>
Date: Fri, 24 Jul 2015 09:05:32 +0000

Hello all,

I would like to expand a bit on the need for a PEER report by an abatement algorithm, what I do not think is correct.
This is being commented in previous question "[Dime] DA overload comment on 3.2 Diameter end-point use cases", but I would like to provide some reflections as well on the RATE draft in this respect.

Therefore my comments affect both draft-ietf-dime-doic-rate-control and  draft-ietf-dime-agent-overload.
I will split my comment to make it is easier to reply and act upon:

a)      RATE draft, PEER usage:
In Rate draft,   draft-ietf-dime-doic-rate-control-01, it is somehow assumed that the Report Type to be used is "Peer", in fact, we still have an Open Issue about whether it is applicable to Host and Realm report.  See clause 3, "Interaction with DOIC report types":

3.  Interaction with DOIC report types

   As of the publication of this specification there are two DOIC report

   types defined with the specification of a third in progress:

   1.  Host - Overload of a specific Diameter Application at a specific

       Diameter Node as defined in [I-D.ietf-dime-ovli].

   2.  Realm - Overload of a specific Diameter Application at a specific

       Diameter Realm as defined in [I-D.ietf-dime-ovli].

   3.  Peer - Overload of a specific Diameter peer as defined in

       [I-D.ietf-dime-agent-overload].

   The rate algorithm MAY be selected by reporting nodes for any of

   these report types.

      Editor's note: It needs to be validated that use of the rate

      algorithm applies to the host and realm report types.

In my opinion, Rate should work with Host and Realm, and as well  with Peer. But whatever it is required should be described in DOIC (host and Realm), and Agent Overload (Peer).
I understand there is a different thing with Rate comparing with the Default algorithm: the reporting node needs to keep track of the "target", since only some Reacting nodes will use Rate. But this does not imply that Host and Realm will not be able to be used. Apart from that, any specifics about the Peer Report Type usage needs to be covered in Agent Overload draft.

b)      AGENT draft, requirement on the PEER usage: to be removed
It seems that in Agent Overload draft it is implied that Rate requires Peer Report Type, what I do not think is right.
See in draft-ietf-dime-agent-overload-01 , clause 3.2:

3.2.  Diameter Endpoint Use Cases

   This section outlines use cases for the peer report feature involving

   Diameter Clients and Diameter Servers.

3.2.1.  Hop-by-hop Abatement Algorithms

   It is envisioned that abatement algorithms will be defined that will

   support the option for Diameter Endpoints to send peer reports.  For

   instance, it is envisioned that one usage scenario for the rate

   algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked

   on by the DIME working group as this is written, will involve

   abatement being done on a hop-by-hop basis.

   This rate deployment scenario would involve Diameter Endpoints

   generating peer reports and selecting the rate algorithm for

   abatement of overload conditions.

I think this paragraph should be removed from Agent Overload draft.

c)       RATE draft, PEER references

On the other hand, there are some other references to PEER Report behavior along draft, that in my opinion should be removed, this should be described only in Agent Overload draft.

See following text:

4.  Capability Announcement

...

      For peer reports the selected algorithm is reflected in the OC-

      Peer-Algo AVP sent as part of the OC-Supported-Features AVP

      included answer messages for transaction where the request

      contained an OC-Supported-Features AVP.  This is per the

      procedures defined in [I-D.ietf-dime-agent-overload].

      Editor's Node: The peer report specification is still under

      development and, as such, the above paragraph is subject to

      change.

5.3.  Reporting Node Maintenance of Overload Control State

...

   o  For Peer reports the target is the DiameterID of the Diameter Peer

      from which the request was received.

6.2.  OC-OLR AVP

   This extension defines the OC-Maximum-Rate AVP to be an optional part

   of the OC-OLR AVP.

      OC-OLR ::= < AVP Header: TBD2 >

                 < OC-Sequence-Number >

                 < OC-Report-Type >

                 [ OC-Reduction-Percentage ]

                 [ OC-Validity-Duration ]

                 [ OC-Source-ID ]

                 [ OC-Abatement-Algorithm ]

                 [ OC-Maximum-Rate ]

               * [ AVP ]

   This extension makes no changes to the other AVPs that are part of

   the OC-OLR AVP.

   This extension does not define new overload report types.  The

   existing report types of host and realm defined in

   [I-D.ietf-dime-ovli] apply to the rate control algorithm.  The peer

   report type defined in [I-D.ietf-dime-agent-overload] also applies to

   the rate control algorithm.

For the last paragraph, remove at least Agent Overload draft is approved.

Best regards
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: lunes, 20 de julio de 2015 17:08
To: [email-masked]
Subject: Re: [Dime] DA overload comment on 3.2 Diameter end-point use cases

JJacques,

Thanks for the comment.

I would assume that the Diameter endpoint (server for this discussion) would send either a peer report or a host report.  There would be no reason for the server to send both.

A host report is processed and passed on by agents.

A peer report is consumed by agents and, most likely, a new peer report is generated by the agent.

The peer report is envisioned to be used for multiple reasons.  The first is defined in the agent overload draft to allow agents to communicate overload state.  The second is for overload abatement algorithms that require peer-to-peer semantics.  The first case of this second usage is the rate overload abatement algorithm.

Regards,

Steve
On 7/20/15 2:46 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
Hi

About DA overload (draft-ietf-dime-agent-overload), I have a comment about section 3.2 (Diameter Endpoint Use Cases) / 3.2.1. I do not well see the reasons  why a server would send "peer overload" reports in addition to the ovli OLRs specified in draft-ietf-dime-ovli , as it creates overlap. The DA is aware that it is a peer of the server; so the DA can handle the received ovli OLRs from the server as peer OLRs if it wants. So I would limit the draft-ietf-dime-agent-overload only to DA overload  and the associated peer overload report to be generated by DA only .

Best regards

JJacques

_______________________________________________

DiME mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/dime