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

[Steve Donovan <[e-mail]>]

Lionel,
Jouni,

I've incorporated all of the suggested changes into the draft.  I 
believe the time period for the WGLC has expired.  Please advise if I 
should publish the new version or if you want to wait for more comments.

Regards,

Steve

On 6/13/16 8:06 AM, [e-mail] wrote:
> Thank you for the useful discussion.
> I'm OK with the output and the proposed changes.
>
> regards,
>
> Lionel
>
>> -----Message d'origine-----
>> De : DiME [mailto:[e-mail]] De la part de Maria Cruz Bartolome
>> Envoyé : vendredi 10 juin 2016 10:02
>> À : Steve Donovan; [e-mail]
>> Objet : Re: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05
>>
>>>>> 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
>>
>> _______________________________________________
>> DiME mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>