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

Steve Donovan <> Mon, 13 June 2016 20:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06E6212D957 for <>; Mon, 13 Jun 2016 13:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KOAm0HoYt16Y for <>; Mon, 13 Jun 2016 13:15:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2955D12D681 for <>; Mon, 13 Jun 2016 13:14:25 -0700 (PDT)
Received: from ([]:60665 helo=Steves-MacBook-Air.local) by with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from <>) id 1bCYFZ-000S9h-1y; Mon, 13 Jun 2016 13:14:25 -0700
To:, Maria Cruz Bartolome <>, "" <>
References: <> <> <> <> <> <> <> <> <6945_1465823177_575EAFC9_6945_1776_1_6B7134B31289DC4FAF731D844122B36E01EB0E02@OPEXCLILM43.corporate.adroot.infra.ftgroup>
From: Steve Donovan <>
Message-ID: <>
Date: Mon, 13 Jun 2016 15:14:19 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <6945_1465823177_575EAFC9_6945_1776_1_6B7134B31289DC4FAF731D844122B36E01EB0E02@OPEXCLILM43.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-OutGoing-Spam-Status: No, score=-0.2
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Jun 2016 20:15:16 -0000


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.



On 6/13/16 8:06 AM, wrote:
> Thank you for the useful discussion.
> I'm OK with the output and the proposed changes.
> regards,
> Lionel
>> -----Message d'origine-----
>> De : DiME [] De la part de Maria Cruz Bartolome
>> Envoyé : vendredi 10 juin 2016 10:02
>> À : Steve Donovan;
>> 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
> _________________________________________________________________________________________________________________________
> 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.