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

From: Steve Donovan <[email-masked]>
Date: Tue, 04 Aug 2015 08:10:42 -0500

Maria Cruz,

Thank you for the reviews.  See my comments inline.

Regards,

Steve

On 7/24/15 4:05 AM, Maria Cruz Bartolome wrote:
>
> 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-controland 
> 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.
>
SRD> I agree that the current writing of the draft is focused on the use 
of the rate algorithm in a peer report.  I intentionally put the 
editor's note in the document to make sure that we have the discussion 
on whether or not there is reason to also allow use of the rate 
algorithm in host and realm reports.

SRD> It is, however, not clear to me how rate would be an effective 
overload control mechanism in host reports, at least not in the general 
sense.  Any time that a Diameter application allows for realm routed 
requests to be sent by a client it becomes impossible for a client to 
know the rate of requests that will arrive at a specific server.  I'd 
like to see some thought put into how this would work before indicating 
support for it in the rate draft.

SRD> I agree there may be times that a reporting nodes sends both rate 
and loss reports.  I would expect this to be in transition periods as an 
operator turns on rate control.  It seems, however, more likely that an 
operator would turn on rate between a reporting node and the first hop 
agents first and, if needed, have the agent translate rate OLRs into 
loss OLRs for reacting nodes that do not support rate.
>
> *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.
>
SRD> I don't see why.  This is an explanation of how peer might be used, 
not a prescription that it must happen.
>
> *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].
>
SRD> This is explicitly referring back to the agent overload draft, 
where, I agree, the behavior is to be defined.
>
>       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.
>
SRD> I don't understand what is being proposed but the rate algorithm 
has a dependency on the agent overload draft because at least one of the 
report types it needs to support is peer, and peer is defined in the 
agent overload draft.
>
> 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
>
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Wed, 5 Aug 2015 09:10:55 +0000

Hello Steve,
Thanks for your response.
See my comments below
Best regards
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: martes, 04 de agosto de 2015 15:11
To: [email-masked]
Subject: Re: [Dime] PEER Report with RATE algorithm (Agent Overload + Rate Algorithm drafts)

Maria Cruz,

Regards,

Steve

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

   these 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.
SRD> I agree that the current writing of the draft is focused on the use of the rate algorithm in a peer report.  I intentionally put the editor's note in the document to make sure that we have the discussion on whether or not there is reason to also allow use of the rate algorithm in host and realm reports.

SRD> It is, however, not clear to me how rate would be an effective overload control mechanism in host reports, at least not in the general sense.  Any time that a Diameter application allows for realm routed requests to be sent by a client it becomes impossible for a client to know the rate of requests that will arrive at a specific server.  I'd like to see some thought put into how this would work before indicating support for it in the rate draft.
MCRUZ> I do not understand your concern. A rate of message will be ensure in the reacting node either for a particular host or for a realm. Could you clarify please?

SRD> I agree there may be times that a reporting nodes sends both rate and loss reports.  I would expect this to be in transition periods as an operator turns on rate control.  It seems, however, more likely that an operator would turn on rate between a reporting node and the first hop agents first and, if needed, have the agent translate rate OLRs into loss OLRs for reacting nodes that do not support rate.
MCRUZ> Not sure how this is related to the discussion here

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:

I think this paragraph should be removed from Agent Overload draft.
SRD> I don't see why.  This is an explanation of how peer might be used, not a prescription that it must happen.
MCRUZ> "this section outlines use cases for the peer report feature involving Clients and Servers". Why is this needed? I think the Agent draft should cover only Agent overload use cases, nothing else.

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:

...

      procedures defined in [I-D.ietf-dime-agent-overload].
SRD> This is explicitly referring back to the agent overload draft, where, I agree, the behavior is to be defined.
MCRUZ> then do you agree about removal?

      change.

...

6.2.  OC-OLR AVP

   of the OC-OLR AVP.

                 < OC-Sequence-Number >

                 < OC-Report-Type >

                 [ OC-Validity-Duration ]

                 [ OC-Source-ID ]

                 [ OC-Maximum-Rate ]

               * [ AVP ]

   the OC-OLR AVP.

For the last paragraph, remove at least Agent Overload draft is approved.
SRD> I don't understand what is being proposed but the rate algorithm has a dependency on the agent overload draft because at least one of the report types it needs to support is peer, and peer is defined in the agent overload draft.
MCRUZ> my point is that what belongs to Agent overload's draft shall be only in Agent overload's draft. I highlighted paragraphs above that belongs to Agent overload's draft.

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]<mailto:[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 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

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

DiME mailing list

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

---

From: Steve Donovan <[email-masked]>
Date: Wed, 05 Aug 2015 16:31:28 -0500

Maria Cruz,

The agent overload draft is defining a new type of overload report -- 
the peer report.  While agent overload handling is the primary use case 
for this overload report type, it is not the only.  It is better to 
define one generic capability then to partially define it in the agent 
overload draft for one set of use cases and then extend the definition 
in a separate draft for another set of use cases. Especially when those 
two sets of use cases are understood at the time of writing.

This is why I added the use case description in section 3.2.

We should define peer report handling as completely as possible in the 
agent overload draft.  If the name of the draft is confusing then we 
should consider changing the name of the draft to reflect this.

The rate draft should then focus on the definition of the rate algorithm 
and how it is used in various overload report types.

I'll send a separate response on the question of whether or not a rate 
overload report makes sense in a host report.

Regards,

Steve

On 8/5/15 4:10 AM, Maria Cruz Bartolome wrote:
> *Sent:* martes, 04 de agosto de 2015 15:11
> *To:* [email-masked]
> *Subject:* Re: [Dime] PEER Report with RATE algorithm (Agent Overload 
> + Rate Algorithm drafts)
>
> Maria Cruz,
>
>     Therefore my comments affect both
>     draft-ietf-dime-doic-rate-controland draft-ietf-dime-agent-overload.
>
>     a)*RATE draft, PEER usage: *
>
>     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”:
>
>     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.
>
> SRD> I agree that the current writing of the draft is focused on the 
> use of the rate algorithm in a peer report.  I intentionally put the 
> overload control mechanism in host reports, at least not in the 
> general sense.  Any time that a Diameter application allows for realm 
> routed requests to be sent by a client it becomes impossible for a 
> client to know the rate of requests that will arrive at a specific 
> server.  I'd like to see some thought put into how this would work 
> before indicating support for it in the rate draft.
> MCRUZ> I do not understand your concern. A rate of message will be 
> ensure in the reacting node either for a particular host or for a 
> realm. Could you clarify please?
>
>
> and loss reports.  I would expect this to be in transition periods as 
> an operator turns on rate control. It seems, however, more likely that 
> an operator would turn on rate between a reporting node and the first 
> hop agents first and, if needed, have the agent translate rate OLRs 
> into loss OLRs for reacting nodes that do not support rate.
> b)*AGENT draft, requirement on the PEER usage: to be removed*
>
> SRD> I don't see why. This is an explanation of how peer might be 
> used, not a prescription that it must happen.
> MCRUZ> “this section outlines use cases for the peer report feature 
> involving Clients and Servers”. Why is this needed? I think the Agent 
> draft should cover only Agent overload use cases, nothing else.
>
> c)*RATE draft, PEER references*
>
> has a dependency on the agent overload draft because at least one of 
> the report types it needs to support is peer, and peer is defined in 
> the agent overload draft.
> MCRUZ> my point is that what belongs to Agent overload’s draft shall 
> be only in Agent overload’s draft. I highlighted paragraphs above that 
> belongs to Agent overload’s draft.
>
> Best regards
>
> /MCruz
>
> *To:* [email-masked] <mailto:[email-masked]>

---

From: Steve Donovan <[email-masked]>
Date: Wed, 05 Aug 2015 17:15:29 -0500

There is an open question in the rate draft as to whether or not the 
rate abatement algorithm should be supported in host overload reports 
with the implication that the server is controlling the maximum rate of 
Diameter traffic sent to the server from a single client.

The draft outlines use of the rate algorithm in peer reports (which are 
defined in the agent overload draft).  This can be used in both agent 
based and non agent based networks to effectively control the rate 
arriving at the overloaded server as the server explicitly knows the 
identity of all peers and can allocate traffic between them.  The peers 
also know what traffic would normally be sent to the endpoint and can 
effectively apply abatement strategies to control the traffic actually 
sent to that endpoint.

The question is whether it makes sense to support the rate algorithm in 
host and realm reports.  I'm ignoring realm reports for the time being 
but I suspect similar considerations exist for realm reports as for host 
reports.

My concerns with this scenario are the following:

First, the overloaded server doesn't have full knowledge of all sources 
(client endpoints) of traffic.  This however can be learned by the 
server remembering the identity of all clients sending it traffic.  
There currently isn't a requirement that the server remember the source 
of all clients supporting DOIC so this would be new functionality.

Second, endpoints (clients) do not know where all of the Diameter 
requests it generates will be routed.  Clients send two types of 
traffic, host routed and realm routed requests.  What does a client do 
when it receives a Host:Rate report indicating a maximum rate to be sent 
to the server from that client?  All that the client can do to influence 
the amount of traffic sent to the overloaded server is to apply 
abatement treatment to host routed requests targeted for that server.  
This is unlikely to match the servers expectation when sending the 
Host:Rate report.  I guess the client could throttle a percentage of the 
realm routed requests based on an algorithm including usual percentage 
of realm routed requests and number of servers that might eventually 
handle those requests but this seems pretty convoluted and unlikely to 
accurately control traffic sent to the server.

We addressed this issue with Host:Loss reports by splitting the 
abatement handling between the endpoint (which handles abatement of host 
routed requests) and last-hop agents (which handle abatement of realm 
routed requests).  This works because the loss algorithm is stateless.  
If we keep this split for Host:Rate reports then there is the need for 
shared information between clients and agents to control the amount of 
traffic sent to a server.  The actual rate of traffic sent to the server 
would be the sum of all host routed requests allowed by all clients plus 
the sum of all realm routed requests allowed by all agents.  I 
personally don't think we want to try to specify how this exchange of 
state would work and how it would then be used to make throttling decisions.

My recommendation, if it isn't obvious from the above, is that we limit 
support for the rate algorithm to peer reports.  If we come up with an 
elegant way of addressing the above concerns sometime in the future then 
that could be a new extension draft.

Regards,

Steve

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 10 Aug 2015 14:55:39 +0000

Hello Steve,

If the intention with the now called Diameter Agent Overload draft is to cover some more generic use cases I think we should extend the title and the scope probably.
Let's see what others think.

And then in the Rate draft, the definition of anything related to PEER reports should be omitted, the right place is the Agent draft.

Best regards
/MCruz

From: Steve Donovan [mailto:[email-masked]]
Sent: miércoles, 05 de agosto de 2015 23:31
To: Maria Cruz Bartolome; [email-masked]
Subject: Re: [Dime] PEER Report with RATE algorithm (Agent Overload + Rate Algorithm drafts)

Maria Cruz,

The agent overload draft is defining a new type of overload report -- the peer report.  While agent overload handling is the primary use case for this overload report type, it is not the only.  It is better to define one generic capability then to partially define it in the agent overload draft for one set of use cases and then extend the definition in a separate draft for another set of use cases.  Especially when those two sets of use cases are understood at the time of writing.

We should define peer report handling as completely as possible in the agent overload draft.  If the name of the draft is confusing then we should consider changing the name of the draft to reflect this.

The rate draft should then focus on the definition of the rate algorithm and how it is used in various overload report types.

I'll send a separate response on the question of whether or not a rate overload report makes sense in a host report.

Regards,

Steve

Maria Cruz,

Regards,

Steve

   these report types.

See following text:

...

      change.

...

6.2.  OC-OLR AVP

   of the OC-OLR AVP.

                 < OC-Sequence-Number >

                 < OC-Report-Type >

                 [ OC-Validity-Duration ]

                 [ OC-Source-ID ]

                 [ OC-Maximum-Rate ]

               * [ AVP ]

   the OC-OLR AVP.

Best regards
/MCruz

JJacques,

Thanks for the comment.

Regards,

Steve

Best regards

JJacques

DiME mailing list

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Tue, 18 Aug 2015 12:45:56 -0500

Maria Cruz,

I am okay with changing the name of the Agent Overload draft to 
something like Diameter Peer Report type if the group feels there is a 
need to do so.

Lionel,
Jouni,

Please advise on whether or not you think this change is needed.

Regards,

Steve

On 8/10/15 9:55 AM, Maria Cruz Bartolome wrote:
>
> Hello Steve,
>
> If the intention with the now called Diameter Agent Overload draft is 
> to cover some more generic use cases I think we should extend the 
> title and the scope probably.
>
> Let’s see what others think.
>
> And then in the Rate draft, the definition of anything related to PEER 
> reports should be omitted, the right place is the Agent draft.
>
> Best regards
>
> /MCruz
>
> *From:*Steve Donovan [mailto:[email-masked]]
> *Sent:* miércoles, 05 de agosto de 2015 23:31
> *To:* Maria Cruz Bartolome; [email-masked]
> the peer report.  While agent overload handling is the primary use 
> case for this overload report type, it is not the only.  It is better 
> to define one generic capability then to partially define it in the 
> agent overload draft for one set of use cases and then extend the 
> definition in a separate draft for another set of use cases.  
> Especially when those two sets of use cases are understood at the time 
> of writing.
>
> The rate draft should then focus on the definition of the rate 
> algorithm and how it is used in various overload report types.
>
>     *Subject:* Re: [Dime] PEER Report with RATE algorithm (Agent
>     Overload + Rate Algorithm drafts)
>
>     Maria Cruz,
>
>         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.
>
>         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”:
>
>         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.
>
>     SRD> I agree that the current writing of the draft is focused on
>     the use of the rate algorithm in a peer report.  I intentionally
>     put the editor's note in the document to make sure that we have
>     the discussion on whether or not there is reason to also allow use
>     of the rate algorithm in host and realm reports.
>
>     SRD> It is, however, not clear to me how rate would be an
>     effective overload control mechanism in host reports, at least not
>     in the general sense.  Any time that a Diameter application allows
>     for realm routed requests to be sent by a client it becomes
>     impossible for a client to know the rate of requests that will
>     arrive at a specific server.  I'd like to see some thought put
>     into how this would work before indicating support for it in the
>     rate draft.
>     SRD> I agree there may be times that a reporting nodes sends both
>     rate and loss reports.  I would expect this to be in transition
>     periods as an operator turns on rate control.  It seems, however,
>     more likely that an operator would turn on rate between a
>     reporting node and the first hop agents first and, if needed, have
>     the agent translate rate OLRs into loss OLRs for reacting nodes
>     that do not support rate.
>     It seems that in Agent Overload draft it is implied that Rate
>     requires Peer Report Type, what I do not think is right.
>
>     MCRUZ> “this section outlines use cases for the peer report
>     feature involving Clients and Servers”. Why is this needed? I
>     think the Agent draft should cover only Agent overload use cases,
>     nothing else.
>
>     SRD> This is explicitly referring back to the agent overload
>     draft, where, I agree, the behavior is to be defined.
>     SRD> I don't understand what is being proposed but the rate
>     algorithm has a dependency on the agent overload draft because at
>     least one of the report types it needs to support is peer, and
>     peer is defined in the agent overload draft.
>     MCRUZ> my point is that what belongs to Agent overload’s draft
>     shall be only in Agent overload’s draft. I highlighted paragraphs
>     above that belongs to Agent overload’s draft.
>
>     Best regards
>
>     /MCruz
>
>     *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.
>
>     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
>
>         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
>
>
>
>
>
>

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 18 Aug 2015 11:24:40 -0700

Steve,

Changing the I-D name (but keeping the file name) is not a big issue if 
that brings clarity. I am OK for it if there are more voices for it than 
just Maria.

- Jouni