Re: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05
Steve Donovan <srdonovan@usdonovans.com> Mon, 13 June 2016 20:15 UTC
Return-Path: <srdonovan@usdonovans.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 06E6212D957 for <dime@ietfa.amsl.com>; Mon, 13 Jun 2016 13:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOAm0HoYt16Y for <dime@ietfa.amsl.com>; Mon, 13 Jun 2016 13:15:14 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2955D12D681 for <dime@ietf.org>; Mon, 13 Jun 2016 13:14:25 -0700 (PDT)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:60665 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from <srdonovan@usdonovans.com>) id 1bCYFZ-000S9h-1y; Mon, 13 Jun 2016 13:14:25 -0700
To: lionel.morand@orange.com, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>, "dime@ietf.org" <dime@ietf.org>
References: <5bba2470-8921-f7db-0f1b-aad280eae684@gmail.com> <087A34937E64E74E848732CFF8354B92181E2DAF@ESESSMB101.ericsson.se> <0f981f69-cea1-6cc4-6837-213d27649963@usdonovans.com> <087A34937E64E74E848732CFF8354B92181F08F6@ESESSMB101.ericsson.se> <77df2a07-ca55-df36-30bb-87a2ff506418@usdonovans.com> <087A34937E64E74E848732CFF8354B92181F1907@ESESSMB101.ericsson.se> <004a3446-c750-05e8-7444-673a14cc10c3@usdonovans.com> <087A34937E64E74E848732CFF8354B92181F1F8F@ESESSMB101.ericsson.se> <6945_1465823177_575EAFC9_6945_1776_1_6B7134B31289DC4FAF731D844122B36E01EB0E02@OPEXCLILM43.corporate.adroot.infra.ftgroup>
From: Steve Donovan <srdonovan@usdonovans.com>
Message-ID: <c03f4e28-a579-c583-e083-87ac6b085633@usdonovans.com>
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 - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/LWmHTmPKrPXHpw_pHtZh8E0oqhE>
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: Mon, 13 Jun 2016 20:15:16 -0000
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, lionel.morand@orange.com 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:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome >> Envoyé : vendredi 10 juin 2016 10:02 >> À : Steve Donovan; dime@ietf.org >> 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 >> DiME@ietf.org >> 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. >
- Re: [Dime] RE : Re: WGLC #1 for draft-ietf-dime-a… Steve Donovan
- Re: [Dime] RE : Re: WGLC #1 for draft-ietf-dime-a… lionel.morand
- Re: [Dime] RE : Re: WGLC #1 for draft-ietf-dime-a… Steve Donovan
- Re: [Dime] RE : Re: WGLC #1 for draft-ietf-dime-a… lionel.morand
- Re: [Dime] RE : Re: WGLC #1 for draft-ietf-dime-a… Steve Donovan
- Re: [Dime] RE : Re: WGLC #1 for draft-ietf-dime-a… Steve Donovan
- Re: [Dime] RE : Re: WGLC #1 for draft-ietf-dime-a… lionel.morand
- [Dime] WGLC #1 for draft-ietf-dime-agent-overload… Jouni Korhonen
- Re: [Dime] WGLC #1 for draft-ietf-dime-agent-over… Maria Cruz Bartolome
- Re: [Dime] WGLC #1 for draft-ietf-dime-agent-over… A. Jean Mahoney
- [Dime] FW: WGLC #1 for draft-ietf-dime-agent-over… Maria Cruz Bartolome
- Re: [Dime] FW: WGLC #1 for draft-ietf-dime-agent-… Steve Donovan
- Re: [Dime] WGLC #1 for draft-ietf-dime-agent-over… Steve Donovan
- Re: [Dime] WGLC #1 for draft-ietf-dime-agent-over… Steve Donovan
- Re: [Dime] WGLC #1 for draft-ietf-dime-agent-over… Maria Cruz Bartolome
- [Dime] RE : Re: WGLC #1 for draft-ietf-dime-agent… lionel.morand
- Re: [Dime] WGLC #1 for draft-ietf-dime-agent-over… Steve Donovan
- Re: [Dime] WGLC #1 for draft-ietf-dime-agent-over… Steve Donovan
- Re: [Dime] WGLC #1 for draft-ietf-dime-agent-over… A. Jean Mahoney
- Re: [Dime] WGLC #1 for draft-ietf-dime-agent-over… Maria Cruz Bartolome
- Re: [Dime] WGLC #1 for draft-ietf-dime-agent-over… Steve Donovan
- Re: [Dime] WGLC #1 for draft-ietf-dime-agent-over… Steve Donovan
- Re: [Dime] WGLC #1 for draft-ietf-dime-agent-over… Steve Donovan
- Re: [Dime] WGLC #1 for draft-ietf-dime-agent-over… Maria Cruz Bartolome
- Re: [Dime] WGLC #1 for draft-ietf-dime-agent-over… lionel.morand