Re: [Dime] WGLC #3 for draft-ietf-dime-doic-rate-control-04
Steve Donovan <srdonovan@usdonovans.com> Thu, 16 February 2017 19:47 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 617081294A5 for <dime@ietfa.amsl.com>; Thu, 16 Feb 2017 11:47:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 rWFCGJJdYKDn for <dime@ietfa.amsl.com>; Thu, 16 Feb 2017 11:47:54 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.250]) (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 7C6F5128E18 for <dime@ietf.org>; Thu, 16 Feb 2017 11:47:54 -0800 (PST)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:51700 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <srdonovan@usdonovans.com>) id 1ceS1r-0046UA-UA for dime@ietf.org; Thu, 16 Feb 2017 11:47:54 -0800
To: dime@ietf.org
References: <DD4AC7F3-F1B3-4891-9399-915F260533B5@gmail.com> <CABPQr27tFPL7qpB3JHz=z6i7Og0eeW6jigVuQDrLsGFxtV=HVQ@mail.gmail.com>
From: Steve Donovan <srdonovan@usdonovans.com>
Message-ID: <ca6a0e9e-6ef8-c496-3ec9-7906fa026434@usdonovans.com>
Date: Thu, 16 Feb 2017 13:47:46 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CABPQr27tFPL7qpB3JHz=z6i7Og0eeW6jigVuQDrLsGFxtV=HVQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------E2F73239CCFD36E0CB084577"
X-OutGoing-Spam-Status: No, score=-1.0
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/IZmj5W9JE3V4ztQPn02CRY_efNs>
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: Thu, 16 Feb 2017 19:47:56 -0000
Misha, Thanks for the review. Please find my comments inline. Regards, Steve On 1/26/17 3:35 PM, Misha Zaytsev wrote: > Hi, > > Here are my comments to the draft: > > 1. section 1. > If the service requests that result in Diameter transactions*increase *quickly... > SRD> Updated > 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. > SRD> Updated > 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. > SRD> Updated > 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. SRD> I think it is better to have the motivating text in this section. > > 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. > SRD> I've changed it to add the following "...make the situation worse by causing wide fluctuations in traffic on multiple nodes in the Diameter network." > 5. section 5.1/general > > report-type -> report type > DiameterID -> DiameterIdentity SRD> Updated > > 6. section 5.5./general > > Rate algorithm -> rate algorithm (if not at the beginning of the > statement) SRD> Updated > > 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. > SRD> Updated > 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*. > SRD> I disagree. This is saying that those procedures apply. I've left the wording as is. > 9. section 6.1.1 > > Probably, it is better to use bit representation of 4, isn't it? > > OLR_RATE_ALGORITHM (0x000000000000000*100*) > SRD> No, this is the hex representation of the field. > 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. > SRD> Updated > 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? SRD> I don't see where this section hurts. It provides context for the rest of section 7. > > 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... SRD> Opinion noted. That was an alternative method that could have been taken. > 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? SRD> Correct > > 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. > SRD> All of this was pulled from the SIP RFC section that describes the rate algorithm. Some of this is repeated but adds context for the description of the algorithm. > 13. Upper case in section titles for section 7.3.1, 7.3.2, 7.3.3, 8.1 > and 8.2 SRD> Updated > > 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. > SRD> The original wording is correct. Those considerations apply to this specifications. > 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 > <mailto: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 <mailto:DiME@ietf.org> > https://www.ietf.org/mailman/listinfo/dime > <https://www.ietf.org/mailman/listinfo/dime> > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime
- [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