Re: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05

[Steve Donovan <[e-mail]>]

On 6/7/16 1:54 AM, Maria Cruz Bartolome wrote:
> Hello Steve,
> Thanks for your reply.
> See some comments below, just keeping relevant parts of my first email, those that still need clarification.
> Best regards
> /MCruz
>
>
>
>> 2. Clause 5.2.3
>>     "In all cases, if the reacting node is a relay then it MUST strip the
>>      OC-OLR AVP from the message."
>>
>>      But, will the relay react against the overload report received? i.e. is it a "reacting node" or it is just relaying the message?
> SRD> That is determined by the other statements in that section. If the
> SourceID received in the message matches that of a peer then the relay is a reacting node.  If it doesn't match then it is not a reacting node.  Either way, the OC-OLR AVP is stripped.
>
> MCRUZ> But a relay can't be a "reacting node", can it? A relay does not read or understand any AVP apart from routing related AVPs.
SRD> Yes a relay is the reacting node for any next hop that generates a 
peer overload report.  As with base DOIC, a relay must be able to handle 
DOIC AVPs, in addition to the routing AVPs.
>
>>     
>> 2. Clause 3:
>>
>> Now:
>>      This section outlines representative use cases for the peer report
>>      used to communicate agent overload.
>>      There are two primary classes of use cases currently identified,
>>      those involving the overload of agents and those involving overload
>>      of Diameter endpoints (Diameter Clients and Diameter Servers) that
>>      wish to use an overload algorithm suited controlling traffic sent
>>      from a peer.
>>
>> Proposed:
>>      This section outlines representative use cases for the peer report
>>      used.
>>      There are two primary classes of use cases currently identified,
>>      those involving the overload of agents and those involving overload
>>      of Diameter endpoints that
>>      wish to use an overload algorithm that requires controlling traffic sent
>>      towards peers.
>>
>> Reasoning:
>>     For the second use case considered the peer report does not communicate agent overload, but Diameter server overload.
>>     Diameter Endpoint is already defined.
>>    Last sentence as it is, it is a bit difficult to understand.
> SRD> I agree to removing the parenthetical.
>
> SRD> I propose changing the paragraph to the following:
>
>      There are two primary classes of use cases currently identified,
>      those involving the overload of agents and those involving overload
>      of Diameter endpoints.  In both cases the goal is to use an overload
>      algorithm that controls traffic sent towards peers.
>
> MCRUZ> Ok
>
>
>> 3. Clause 3.1.1
>>
>> Now:
>> This will result in the throtting of the abated traffic
>>      that would have been sent to the agent, as there is no alternative
>>      route, with the appropriate indication given to the service request
>>      that resulted in the need for the Diameter transaction.
>>
>> Proposed:
>>     This will result in the queuing (temporally at least) and/or the throttling of the abated traffic
>>      that would have been sent to the agent, as there is no alternative
>>      route.
>>
>> Reasoning:
>>      Traffic could be queued, at least temporally, before being throttled.
>>      I do not think it is required to inform about what is sent back to the originator of the initial request.
> SRD> This talks about the abated traffic.  As such, any queuing that
> might have been used as already been done.
>
> SRD> I also think that we should be explicit that a response is sent
> back to the originator of the request.  It would do more harm if
> throttling were interpreted as just dropping the message on the floor.
>
> MCRUZ> Ok, but I suggest we rephrase a bit the sentence, is a bit blurry.  Like e.g.:
>    This will result in the throttling of the abated traffic
>     that would have been sent to the agent, as there is no alternative
>     route. An appropriate error response is sent back to the originator of the request.
SRD> I'm okay with this change.
>
>
>
>> 7. Clause 3.1.3
>>
>> "Another example of this type of
>>      deployment is when there are multiple sets of servers, each
>>      supporting a subset of the Diameter traffic."
>>
>>     This example does not include an "agent chain", since for each Client-Server connection there is only one single Agent in the chain, right?
> SRD> I don't understand why there would be a single agent in the chain.
> It is valid (and done) to have multiple agents between clients and
> servers in this scenario.
>
> MCRUZ> The possibility to have multiple agents in a chain is covered by the previous sentence in same paragraph. This sentence here seems to point out that
> There may be different set of servers, and my understanding is that there may be a chain of agents for each set.
> Therefore, I think this sentence here can be removed, or clarified.
SRD> I agree, it can be removed.
>
>
>> 8. Clause 4
>>
>> "Any messages that survive throttling due
>>      to host or realm reports should then go through abatement for the
>>      peer overload report."
>>
>>     There is an interaction between PEER and HOST reports. The reduction of traffic towards a HOST reduces as well the traffic through the agents in the path. This should be taken into account when applying reduction for that particular PEER. However, depending on the routing schema it may not be straight forward to identify what is the reduction for each agent path when reducing traffic towards a HOST.
> SRD> The goal of this statement is to say that when a Diameter node is
> applying overload abatement algorithms, the order in which active
> overload reports are applied is host/realm report first and then peer
> report.  In other words, abatement is done for traffic being sent to a
> host and then independent abatement is done for the peer to which the
> request is to be routed.  If these are treated as independent actions
> then I don't understand the issue you are raising.
>
> MCRUZ> If you think the PEER algorithm is RATE, then there is not interaction, as long as when PEER abatement is performed after HOST/REALM, it simply keeps a RATE. However, if the PEER algorithm is LOSS, when performed after HOST/REALM it should be stated that it is the initial traffic (before any HOST/REALM abatement) the one that should be taken into account. Then, I think a clarification is required.
SRD> While it is true that, as stated, the presence of a HOST LOSS 
report and a peer LOSS report could result in extra messages being 
abated, I would prefer to keep the definition of the interaction as 
simple as possible and not change the requirement. My reasoning is that 
there is value in keeping it simple, especially given that it a self 
correcting scenario.  The next hop will see more of a reduction than it 
was expecting and will subsequently update the requested reduction.  If 
there isn't consensus on this approach we can do a special case on this 
scenario.

>
>
>