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

Maria Cruz Bartolome <> Thu, 09 June 2016 06:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B9E6012D097 for <>; Wed, 8 Jun 2016 23:16:47 -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 y9nEETvUbX8Y for <>; Wed, 8 Jun 2016 23:16:46 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0F01F12B01E for <>; Wed, 8 Jun 2016 23:16:45 -0700 (PDT)
X-AuditID: c1b4fb25-f79f26d00000327e-a9-575909cbdbda
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 9E.0A.12926.BC909575; Thu, 9 Jun 2016 08:16:44 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0294.000; Thu, 9 Jun 2016 08:16:43 +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/Kx0EggA0O0gCABcD44IACTr0AgADbUwA=
Date: Thu, 09 Jun 2016 06:16:42 +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+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7tO4Zzshwgz19nBZze1ewWWxo4nFg 8liy5CeTx6q3fawBTFFcNimpOZllqUX6dglcGYcWHGQp+CdVsWzJc7YGxpWiXYycHBICJhIv 329jgbDFJC7cW8/WxcjFISRwhFGiv20qE4SzmFFi2e0ZYFVsAnYSl06/YAKxRQR8JY53ngaL Cws4SqzdPoMRIu4k8e3AQ1YI209i3cOF7CA2i4CKxLsvd5m7GDk4eIF6u1bUQMzfwiSxpH83 G0gNJ1DvgVPnwXoZgS76fmoN2C5mAXGJW0/mM0FcKiCxZM95ZghbVOLl43+sELaixM6z7cwQ 9ToSC3Z/YoOwtSWWLXwNFucVEJQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMYoWpxYn5aYb GeulFmUmFxfn5+nlpZZsYgTGycEtv1V3MF5+43iIUYCDUYmHN2FqRLgQa2JZcWXuIUYJDmYl Ed5i9shwId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rz+LxXDhQTSE0tSs1NTC1KLYLJMHJxSDYx1 v3on7+tSnhtUdHkt/+ySTK9W/g+B/0y4r0n8z+qPE9+2/MmFNCPZcskJR2XT2RZ4SNwzPMMz /ZUza4qe8szUgqjtky+ueHJ1Utz+A6sDWeR9QwwfvV6/RNeexWuC+tUlx26c3B6XI6bP7RnD tr7WJ8HH9Yd16HP1d2d/Pw7jYvqeffeOzy8lluKMREMt5qLiRABV8waYjwIAAA==
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: Thu, 09 Jun 2016 06:16:48 -0000

Hello Steve,
See some responses below

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

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