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

Maria Cruz Bartolome <> Fri, 10 June 2016 08:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8522412B04E for <>; Fri, 10 Jun 2016 01:02:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6PRsimeoFTze for <>; Fri, 10 Jun 2016 01:02:26 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 460B212B01E for <>; Fri, 10 Jun 2016 01:02:26 -0700 (PDT)
X-AuditID: c1b4fb30-f79486d0000069d0-8a-575a7410b504
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 2A.AF.27088.0147A575; Fri, 10 Jun 2016 10:02:24 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0294.000; Fri, 10 Jun 2016 10:02:23 +0200
From: Maria Cruz Bartolome <>
To: Steve Donovan <>, "" <>
Thread-Topic: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05
Thread-Index: AQHRtScjgLxS0Hs/VUWoFFfQd/sxcp/Kx0EggA0O0gCABcD44IACTr0AgADbUwCAARYYAIAAkBpQ
Date: Fri, 10 Jun 2016 08:02:23 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7t65ASVS4we3/khZze1ewWWxo4nFg 8liy5CeTx6q3fawBTFFcNimpOZllqUX6dglcGV/2/GMumKJacerRN7YGxl7ZLkZODgkBE4mz WyezQ9hiEhfurWfrYuTiEBI4wijxZssdNpCEkMASRolX95lBbDYBO4lLp18wgdgiAr4SxztP s4DYwgKOEmu3z2CEiDtJfDvwkBXCjpJ4274RrJ5FQFWi+/cnsDm8QL1T2icxQizbwCzx+eEV sAQnUPPvXXvAGhiBLvp+ag2YzSwgLnHryXwmiEsFJJbsOc8MYYtKvHz8jxXCVpRof9rACFGv I7Fg9yc2CFtbYtnC11CLBSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjKLFqcVJuelGRnqp RZnJxcX5eXp5qSWbGIFxcnDLb4MdjC+fOx5iFOBgVOLhffAsMlyINbGsuDL3EKMEB7OSCK9Y YFS4EG9KYmVValF+fFFpTmrxIUZpDhYlcV7/l4rhQgLpiSWp2ampBalFMFkmDk6pBsZJ99kt lqXs1lBy5uRxyVhnJvXEq3Clf9GBMxN/18k1TUgv4GPml780ITpPIPF9qfYCY19Dq0e/Yq/s uDFbbnvNJC+FG1OOK+o+kS6car/N6tT8y73yLbOmzY7o15EO/SF1ZcOlg7dMrh7sTZwSOLP+ bM/Cma9+zjTT198R/aqmQayFpXbp71lKLMUZiYZazEXFiQDqWIGAjwIAAA==
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: Fri, 10 Jun 2016 08:02:28 -0000

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