Re: [Dime] WGLC #3 for draft-ietf-dime-doic-rate-control-04
Misha Zaytsev <misha.zaytsev.rus@gmail.com> Wed, 01 February 2017 20:30 UTC
Return-Path: <misha.zaytsev.rus@gmail.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 21F47129581 for <dime@ietfa.amsl.com>; Wed, 1 Feb 2017 12:30:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 jvo-EOg0_bQH for <dime@ietfa.amsl.com>; Wed, 1 Feb 2017 12:30:50 -0800 (PST)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A3012985B for <dime@ietf.org>; Wed, 1 Feb 2017 12:30:49 -0800 (PST)
Received: by mail-lf0-x231.google.com with SMTP id n124so234381761lfd.2 for <dime@ietf.org>; Wed, 01 Feb 2017 12:30:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t0NT82oLVmzNWxux3F7NH1f2AMkbXopTGzQuA4Md0dQ=; b=gIR16XHB+vZahGmOPkGayl+mUg9Yx0CnfrrS/L0TtxOiIuCz+CJwy7nAM3a/7S00Sh Mf8bzr8SIgqLSEscCKy0hFoOqWOn+kR3+daGW/BSfQSZ9+8dLz6jFNpC5Bl77AKVHovO ocTZoBZGlVx7OiLQAE6C+BtLL1WtL38Xu2aScATJq/E4RYqr6qhKIowIUF9ItkE552YP 0eot4jtiltIDO4dkVI14VE4KEo9cFaWwkEAvXqrul80hFopjQxKOHwF/GraxndxMrHTi 62TRF1QW9XFNAcoAEKi4A5HXa6oJvgibE9xTgz8KfNmMkFoWdgTXd/ndBbqGQsmiJ1RB zxug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t0NT82oLVmzNWxux3F7NH1f2AMkbXopTGzQuA4Md0dQ=; b=CiCchC3rMvNqyl5vjBqS8oRTjWA79RdJ0Q6O1tWep5aEfVndOtOgcoV7+ABUe2C9g/ s8Wmog4VlJEnzLklVWL4VPfHhj5a+Sr6e44SAj22egBoFq6x9LmfZyBU3Iqy2L7CkgaO 0CtX4PMsklU9zlbcqpCUmpy4qqlR0BU3LriRoCtY5SrOTIG7hPeMweWI+vm97c8xrNEQ OdZwu7xD6L5mC/MwY4Nj4Iibg4PIJN5lDVl6ZBwtXYOS+Ijbx5wnK/fO8gp65aZrheLB LLK0wTaisotDbG+nMcwiN8f7HZ9aD3yHtNjvBYBTMcxwDmfZol0Ly0FOOBsFyJyaImXX Mu4Q==
X-Gm-Message-State: AIkVDXJB2GUs/q9I2uIcg/rnMrx8aPX55G4i1z/VJgGI6Q7rAK3Flh6RZexCETySwTLumxXK56Ul0dohVGfXtA==
X-Received: by 10.25.68.1 with SMTP id r1mr1786390lfa.86.1485981047687; Wed, 01 Feb 2017 12:30:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.228.12 with HTTP; Wed, 1 Feb 2017 12:30:47 -0800 (PST)
In-Reply-To: <83203e6cd0e94ccc813a26d3289afee7@CSRRDU1EXM025.corp.csra.com>
References: <DD4AC7F3-F1B3-4891-9399-915F260533B5@gmail.com> <CABPQr27tFPL7qpB3JHz=z6i7Og0eeW6jigVuQDrLsGFxtV=HVQ@mail.gmail.com> <83203e6cd0e94ccc813a26d3289afee7@CSRRDU1EXM025.corp.csra.com>
From: Misha Zaytsev <misha.zaytsev.rus@gmail.com>
Date: Wed, 01 Feb 2017 23:30:47 +0300
Message-ID: <CABPQr25_Ncb-RuuMm9qodu8jyyBhP94gFg52S3LsquqnEoc=VQ@mail.gmail.com>
To: "Gunn, Janet P" <Janet.Gunn@csra.com>
Content-Type: multipart/alternative; boundary="94eb2c1ccc2e7d91ff05477dec69"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/uoQfktLu2BCyAKBQPW2UEIp9jxw>
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] WGLC #3 for draft-ietf-dime-doic-rate-control-04
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: Wed, 01 Feb 2017 20:30:53 -0000
Hi Janet, I agree with your argumentation! But let me clarify one point. When I'm saying "less traffic" it means less traffic of a relatively constant amount of inflow (as you also stated). When I'm saying "slower traffic" it means to reduce the traffic inflow rate from a particular reacting node. And yes, both abatement treatments will lead to reduction in a total inflow amount. My comment is just a proposal/idea in which way we can simplify the description. It is up to an author/editor to make a final decision this part can be re-phrased. /Misha 2017-02-01 22:57 GMT+03:00 Gunn, Janet P <Janet.Gunn@csra.com>: > I agree with most of Misha's comments. > > > > The one I do not completely agree with is this: > > > > " Can't it we simplify the description and make it shorter at the same > time? > > Loss algorithm is about the case with a specific traffic rate. Thus, the > amount of the abated traffic directly depends on its rate. > > In this case the reporting node just says to a reacting one: "I want you > to send less traffic". > > While rate algorithm is about the traffic rate itself. In this case a > reporting node says to a reacting one: "I want you to sent traffic slower"" > > > > I agree it would be good to make the description simpler and shorter. > > > > But I do not agree with the suggestion that "Loss = less traffic" and > "Rate = slower traffic". > > > > Both Loss and Rate = less traffic. It is just a difference in how the > "less" is determined. > > > > Loss = "reduce traffic BY x%" > > Rate = "reduce traffic TO y messages per second" > > > > When you have a number of sources, each of which has a relatively > consistent message rate, though some may have higher rates than others, > Loss makes sense. > > - Because each is relatively consistent, reducing "BY x%" is likely to > reduce the offered load to the appropriate level > > - Using "BY x%" spreads the cuts "fairly" across the sources. > > > > When you have a number of sources, each of which has a widely fluctuating > ("bursty") message rate, Loss makes less sense. > > - Because each source is bursty, reducing "BY x%" is likey to cut either > too much (if the message rate drops) or not enough (if the message rate > spikes) > > - Using "TO y messages per second" ensures that the offered load will be > reduced to the appropriate level. > > - It may or may not do it "fairly", depending on whether you give all the > sources the same requested rate, or if you adjust the requested rate based > on the historical, long term, average rate of that source. > > > > Janet > > *From:* DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Misha Zaytsev > *Sent:* Thursday, January 26, 2017 4:36 PM > *To:* jouni.nospam <jouni.nospam@gmail.com> > *Cc:* dime@ietf.org > *Subject:* Re: [Dime] WGLC #3 for draft-ietf-dime-doic-rate-control-04 > > > > Hi, > > > > Here are my comments to the draft: > > > > 1. section 1. > > > > If the service requests that result in Diameter transactions *increase *quickly... > > > > 2. section 1. corrected misprints > > > > Consider the case where a reacting *(?)* node is handling 100 service > > requests per second, where each of these service requests results in > > one Diameter transaction being sent to a *reporting *node. If the > > *reporting *node is approaching an overload state, or is already in an > > overload state, it will send a Diameter overload report requesting a > > percentage reduction in traffic sent. Assume for this discussion > > that the reporting node requests a 10% reduction. The reacting node > > will then abate (diverting or throttling) ten Diameter transactions *per* > > second, sending the remaining 90 transactions per second to the > > *reporting *node. > > > > 3. section 1, reporting nodes -> reporting node's > > > > The reacting node will continue to honor the *reporting node's request* for a 10% reduction in traffic. > > > > 4. section 1, question > > > > Can't it we simplify the description and make it shorter at the same time? > > Loss algorithm is about the case with a specific traffic rate. Thus, the > amount of the abated traffic directly depends on its rate. > > In this case the reporting node just says to a reacting one: "I want you > to send less traffic". > > While rate algorithm is about the traffic rate itself. In this case a > reporting node says to a reacting one: "I want you to sent traffic slower" > > > > This is just an idea/proposal in which way the description can be > simplified. > > If this is the matter of preference, then OK. > > > > Also, could it be clarified the meaning of the following statement? > > What potential to make the situation worse is meant here? > > > > This control feedback loop has the potential to make the situation worse. > > > > 5. section 5.1/general > > > > report-type -> report type > > DiameterID -> DiameterIdentity > > > > 6. section 5.5./general > > > > Rate algorithm -> rate algorithm (if not at the beginning of the statement) > > > > 7. section 5.5 > > > > Probably "MUST" is to be used? > > > > When sending an overload report for the *rate* algorithm, the OC- > > Maximum-Rate AVP *MUST be* included and the OC-Reduction-Percentage AVP *MUST not* > > * be* included. > > > > 8. section 5.6 > > > > Once a determination is made by the reacting node that an individual > > Diameter request is to be subjected to abatement treatment then the > > procedures for throttling and diversion defined in [RFC7683] and > > [I-D.ietf-dime-agent-overload] *are applied*. > > > > 9. section 6.1.1 > > > > Probably, it is better to use bit representation of 4, isn't it? > > > > OLR_RATE_ALGORITHM (0x000000000000000*100*) > > > > 10. section 6.2.1 corrected misprints > > > > The OC-Maximum-Rate AVP (AVP code TBD1) is *of* type Unsigned32 and > > describes the maximum rate *that* the sender is requested to send > > traffic. > > > > 11. section 7.1 > > > > To be honest, I do not see the value of the text in this section. It just > formulates already defined things in a shorter form. > > Is it really worth having it in the spec? > > > > In general, let me state my personal opinion: I think we should take only > really meaningful info from SIP RFC, not just pull the content with the > appropriate changes to be inline with Diameter RFC7683... > > > > 12. section 7.2 > > > > It is clear that the reacting nodes may send less than the specified > OC-Maximum-Rate value. > > They should not send more than the specified OC-Maximum-Rate value, right? > > > > Not sure what is the purpose of the 2nd paragraph... > > > > Note that the AVP for the rate algorithm is an upper bound (in > > request messages per second) on the traffic sent by the reacting node > > to the reporting node. The reacting node may send traffic at a rate > > significantly lower than the upper bound, for a variety of reasons. > > > > In other words, when multiple reacting nodes are being controlled by > > an overloaded reporting node, at any given time some reacting nodes > > may receive requests at a rate below its target maximum Diameter > > request rate while others above that target rate. But the resulting > > request rate presented to the overloaded reporting node will converge > > towards the target Diameter request rate. > > > > The things below are already described in the above sections, aren't they? > > If so, what is the reason behind to duplicate the info? > > > > Upon detection of overload, and the determination to invoke overload > > controls, the reporting node MUST follow the specifications in > > [RFC7683] to notify its clients of the allocated target maximum > > Diameter request rate and to notify them that the rate overload > > abatement is in effect. > > > > The reporting node MUST use the OC-Maximum-Rate AVP defined in this > > specification to communicate a target maximum Diameter request rate > > to each of its clients. > > > > 13. Upper case in section titles for section 7.3.1, 7.3.2, 7.3.3, 8.1 and > 8.2 > > > > 14. section 9. apply-> are applied (if my understanding is correct) > > > > As such, all of the security considerations outlined in [RFC7683] are applied to the rate overload > > abatement mechanism. > > > > If more issues are found, I will add them to the list later on. > > > > Best regards, > > > > /Misha > > > > > > > > 2017-01-23 4:27 GMT+03:00 jouni.nospam <jouni.nospam@gmail.com>: > > Folks, > > This mail starts the WGLC #3 for draft-ietf-dime-doic-rate-control-04. > The WGLC ends next Sunday 2/5/2017 (PDT). > > Please, read & review the draft, provide your support or opposition and/or > comments to the list. > > Just reminding.. no comments/reviews on the document, I cannot conclude > the WGLC has passed. > > > Regards, > Jouni > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > This electronic message transmission contains information from CSRA that > may be attorney-client privileged, proprietary or confidential. The > information in this message is intended only for use by the individual(s) > to whom it is addressed. If you believe you have received this message in > error, please contact me immediately and be aware that any use, disclosure, > copying or distribution of the contents of this message is strictly > prohibited. NOTE: Regardless of content, this email shall not operate to > bind CSRA to any order or other contract unless pursuant to explicit > written agreement or government initiative expressly permitting the use of > email for such purpose. >
- [Dime] WGLC #3 for draft-ietf-dime-doic-rate-cont… jouni.nospam
- Re: [Dime] WGLC #3 for draft-ietf-dime-doic-rate-… Misha Zaytsev
- Re: [Dime] WGLC #3 for draft-ietf-dime-doic-rate-… Gunn, Janet P
- Re: [Dime] WGLC #3 for draft-ietf-dime-doic-rate-… Misha Zaytsev
- Re: [Dime] WGLC #3 for draft-ietf-dime-doic-rate-… Gunn, Janet P
- Re: [Dime] WGLC #3 for draft-ietf-dime-doic-rate-… DOLLY, MARTIN C
- Re: [Dime] WGLC #3 for draft-ietf-dime-doic-rate-… A. Jean Mahoney
- Re: [Dime] WGLC #3 for draft-ietf-dime-doic-rate-… DOLLY, MARTIN C
- Re: [Dime] WGLC #3 for draft-ietf-dime-doic-rate-… jouni.nospam
- Re: [Dime] WGLC #3 for draft-ietf-dime-doic-rate-… Steve Donovan