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

[Maria Cruz Bartolome <[e-mail]>]

Hello Steve,
See some responses below
Thanks
/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 
> SRD> 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.
MCRUZ> In DOIC this is not explicitly mentioned, and I do not see the need. Moreover, this changes the definition of what a relay is. 


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

MCRUZ> I think we need to cover these cases, since having extra throttling even if it is compensated later will cause first unnecessary drop messages and second traffic oscillations. Both things should be avoided.