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

Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> Tue, 07 June 2016 06:54 UTC

Return-Path: <maria.cruz.bartolome@ericsson.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDED12D1AF for <dime@ietfa.amsl.com>; Mon, 6 Jun 2016 23:54:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiH_x2GRgMOL for <dime@ietfa.amsl.com>; Mon, 6 Jun 2016 23:54:40 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60BEE12D188 for <dime@ietf.org>; Mon, 6 Jun 2016 23:54:40 -0700 (PDT)
X-AuditID: c1b4fb2d-f79936d0000030e4-6c-57566fae2807
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 12.F8.12516.EAF66575; Tue, 7 Jun 2016 08:54:38 +0200 (CEST)
Received: from ESESSMB101.ericsson.se ([169.254.1.197]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0294.000; Tue, 7 Jun 2016 08:54:38 +0200
From: Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>
To: Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05
Thread-Index: AQHRtScjgLxS0Hs/VUWoFFfQd/sxcp/Kx0EggA0O0gCABcD44A==
Date: Tue, 7 Jun 2016 06:54:37 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92181F08F6@ESESSMB101.ericsson.se>
References: <5bba2470-8921-f7db-0f1b-aad280eae684@gmail.com> <087A34937E64E74E848732CFF8354B92181E2DAF@ESESSMB101.ericsson.se> <0f981f69-cea1-6cc4-6837-213d27649963@usdonovans.com>
In-Reply-To: <0f981f69-cea1-6cc4-6837-213d27649963@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.147]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7uu66/LBwg7e/NS3m9q5gs9jQxOPA 5LFkyU8mj1Vv+1gDmKK4bFJSczLLUov07RK4Ms5NusZe8Fa/YsWxNSwNjFNVuxg5OSQETCT+ X1jECmGLSVy4t56ti5GLQ0jgCKPEk47rTBDOYkaJKXfusYFUsQnYSVw6/YIJxBYR8JU43nma BcQWFnCUWLt9BiNE3Eni24GHrDD23d97wOIsAioSb89dBYvzAvW+/9kLtW0Ho8SGi7/BijiB Gh7eOwO2gBHopO+n1oDZzALiEreezGeCOFVAYsme88wQtqjEy8f/gIZyANlKEtO2pkGU60gs 2P2JDcLWlli28DUzxF5BiZMzn7BMYBSdhWTqLCQts5C0zELSsoCRZRWjaHFqcXFuupGxXmpR ZnJxcX6eXl5qySZGYJwc3PJbdwfj6teOhxgFOBiVeHgXaIWFC7EmlhVX5h5ilOBgVhLhvZ4G FOJNSaysSi3Kjy8qzUktPsQozcGiJM7r/1IxXEggPbEkNTs1tSC1CCbLxMEp1cDoY93Z19kQ 3hsj8Pf2X/eaE/dZn7D66pueiHhnMXOy++MJD4uWef47G+GucerJC9WX75Qm10SdD/o3V7Ey Nu20sN/mkz92ZEzluiB4OX+zrfmG6bcqSpOmX9vFs7Cbe9Gu8B+aCUFxjtHPXO5/dOaR3H1O o49/zuslPjb1JS9u3+aLM5+4pn2/EktxRqKhFnNRcSIAVsB4MY8CAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/S4zFast71NrXgEgVtoMI3u41XBM>
Subject: Re: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jun 2016 06:54:42 -0000

Hello Steve,
Thanks for your reply.
See some comments below, just keeping relevant parts of my first email, those that still need clarification.
Best regards
/MCruz



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

>    
> 2. Clause 3:
>
> Now:
>     This section outlines representative use cases for the peer report
>     used to communicate agent overload.
>     There are two primary classes of use cases currently identified,
>     those involving the overload of agents and those involving overload
>     of Diameter endpoints (Diameter Clients and Diameter Servers) that
>     wish to use an overload algorithm suited controlling traffic sent
>     from a peer.
>
> Proposed:
>     This section outlines representative use cases for the peer report
>     used.
>     There are two primary classes of use cases currently identified,
>     those involving the overload of agents and those involving overload
>     of Diameter endpoints that
>     wish to use an overload algorithm that requires controlling traffic sent
>     towards peers.
>
> Reasoning:
>    For the second use case considered the peer report does not communicate agent overload, but Diameter server overload.
>    Diameter Endpoint is already defined.
>   Last sentence as it is, it is a bit difficult to understand.
SRD> I agree to removing the parenthetical.

SRD> I propose changing the paragraph to the following:

    There are two primary classes of use cases currently identified,
    those involving the overload of agents and those involving overload
    of Diameter endpoints.  In both cases the goal is to use an overload
    algorithm that controls traffic sent towards peers.

MCRUZ> Ok


> 3. Clause 3.1.1
>
> Now:
> This will result in the throtting of the abated traffic
>     that would have been sent to the agent, as there is no alternative
>     route, with the appropriate indication given to the service request
>     that resulted in the need for the Diameter transaction.
>
> Proposed:
>    This will result in the queuing (temporally at least) and/or the throttling of the abated traffic
>     that would have been sent to the agent, as there is no alternative
>     route.
>
> Reasoning:
>     Traffic could be queued, at least temporally, before being throttled.
>     I do not think it is required to inform about what is sent back to the originator of the initial request.
SRD> This talks about the abated traffic.  As such, any queuing that 
might have been used as already been done.

SRD> I also think that we should be explicit that a response is sent 
back to the originator of the request.  It would do more harm if 
throttling were interpreted as just dropping the message on the floor.

MCRUZ> Ok, but I suggest we rephrase a bit the sentence, is a bit blurry.  Like e.g.:
  This will result in the throttling of the abated traffic
   that would have been sent to the agent, as there is no alternative
   route. An appropriate error response is sent back to the originator of the request.



> 7. Clause 3.1.3
>
> "Another example of this type of
>     deployment is when there are multiple sets of servers, each
>     supporting a subset of the Diameter traffic."
>
>    This example does not include an "agent chain", since for each Client-Server connection there is only one single Agent in the chain, right?
SRD> I don't understand why there would be a single agent in the chain.  
It is valid (and done) to have multiple agents between clients and 
servers in this scenario.

MCRUZ> The possibility to have multiple agents in a chain is covered by the previous sentence in same paragraph. This sentence here seems to point out that 
There may be different set of servers, and my understanding is that there may be a chain of agents for each set. 
Therefore, I think this sentence here can be removed, or clarified.


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