Subject: Re: [Dime] Host report containing rate abatement algorithm (was Re: PEER Report with RATE algorithm (Agent Overload + Rate Algorithm drafts))

From: Steve Donovan <[email-masked]>
Date: Wed, 30 Sep 2015 15:35:50 -0500

All,

I haven't received any feedback on this analysis.  As such, I'm planning 
to update the rate draft to reflect the recommendation that we limit 
support for the rate algorithm to peer reports.

Please let me know if there are concerns with this approach.

Steve

On 8/5/15 5:15 PM, Steve Donovan wrote:
> 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
>
>
> On 8/5/15 4:10 AM, Maria Cruz Bartolome wrote:
>>
>> 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,
>>
>> 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.
>> 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:
>>
>> 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.
>> 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:
>>
>> 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.
>> MCRUZ> then do you agree about removal?
>>
>>       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.
>> 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 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] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/dime
>>
>
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime