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

[<[e-mail]>]

Hi Steve,

Reviewing the draft, I have additional comments that I will post tomorrow.

Regards,

Lionel

Envoyé de mon Orange Nura 2

Le 13 juin 2016 22:14, Steve Donovan <[e-mail]> a écrit :
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.
>


_________________________________________________________________________________________________________________________

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.