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

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

>>> 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 
> SRD> 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.
SRD2> You are correct, it should say agent, not relay.  In my mind an
agent that is a relay can also be a reacting node by expanding the definition of routing related AVPs to include DOIC AVPs.  I consider this valid as these AVPs, and the LOAD AVPs all impact routing decisions.  This, however, is somewhat academic as the practical impact of calling an agent that is a reacting node a relay or a proxy isn't meaningful.

SRD> I'll change the word in the above clause to agent.
MCRUZ> Thanks Steve. I think this change applies to other places in the draft.


>
>>> 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 
>> SRD> 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.
SRD> How about if we add the following:

      Any messages that survive throttling due to host or realm reports should then go through abatement for the
      peer overload report.  In this scenario, when doing abatement on the PEER report, the reacting node SHOULD
      take into consideration the number of messages already throttled by the handling of the HOST/REALM report abatement.

          Note: The goal is to avoid traffic oscillations that might result from throttling of messages for both
          the HOST/REALM overload reports and the PEER overload reports.  This is especially a concern if both
          reports are of type LOSS.

MCRUZ> I think this is fine. Thanks