Re: [Dime] WGLC #3 for draft-ietf-dime-doic-rate-control-04

Misha Zaytsev <misha.zaytsev.rus@gmail.com> Thu, 26 January 2017 21:35 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 391E7129BC8 for <dime@ietfa.amsl.com>; Thu, 26 Jan 2017 13:35:42 -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 CuYj6DKKfriZ for <dime@ietfa.amsl.com>; Thu, 26 Jan 2017 13:35:40 -0800 (PST)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 77E921298CE for <dime@ietf.org>; Thu, 26 Jan 2017 13:35:39 -0800 (PST)
Received: by mail-lf0-x22f.google.com with SMTP id v186so152609458lfa.1 for <dime@ietf.org>; Thu, 26 Jan 2017 13:35:39 -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=3HGGMJv3IstnZ59OhgB6QO4nTM+5HeI3d3k3ihDL4qg=; b=Fs+zTxjP59hxa0fZSS5k+FqsS226wctoPMrgwfinTptgPXS5Cz/aRgpnbEN3bN+jdF Ytk/7JMmZ5cE+SElAJ/fGzEmZ69DIEabPJ+tXw8ltXYNdtV3xIQo2tLg/8y1h2wDuqxv dOtQ4uuvkMiv/WcHGu4ts4Khukkc0s/5Bvu6co8c7GRgDfYjQiyodVtdIs8zgxv+BvEt fjVRHyZQM97p+qHbQt9svuHcZbEw8sN58+MbRiXRPlR2BgvcERiIcXIRra3R4M4Ti8rf UrLXam/04vsBfIWLw2HcJ/tysmJhQl3cUp1KDnBl62q9uI9cCzyrkXB4HWPRhuNkZX6I kWEA==
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=3HGGMJv3IstnZ59OhgB6QO4nTM+5HeI3d3k3ihDL4qg=; b=fXxz9AtSW3n2mZ8xFVh9/rSuCHMEVHcOkvcu2mvtKCTZITwhhDC1EYmZ/p1pyY1FJL CaCtjGVV7oBwnQB2rX9LjyGqPnVAI3XACjoPw3+hwPF/ZOIXyM42uErq/OqoJZxSWKNq wnAIZ11dzmbF4USrvjnkH9Arxvzw4YtUygksHes6zwlZy7WOe0VNMEgifivymuX/F00d xenc7e89zmy66W6q9KZVBVY+xkn+ISJ3mepoq+g2WnqT8UXBl3Vbvni66qRBTvp9LHWM 7GTW3Rx3q4rujlI1duamT2K6PoOI3TF1FjZCn50JxOMKq5YQ6tCkLa/CnzyjbHVVf4lf QqEg==
X-Gm-Message-State: AIkVDXJk4UU4RaxTjy8Svi8v/aC18/yMMayGdwBPjQ5dFWTA3SgMK4D8egTAXl4cqbjEEZayoXPIHHLJGWKSUg==
X-Received: by 10.25.79.79 with SMTP id a15mr1682964lfk.58.1485466537428; Thu, 26 Jan 2017 13:35:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.228.12 with HTTP; Thu, 26 Jan 2017 13:35:36 -0800 (PST)
In-Reply-To: <DD4AC7F3-F1B3-4891-9399-915F260533B5@gmail.com>
References: <DD4AC7F3-F1B3-4891-9399-915F260533B5@gmail.com>
From: Misha Zaytsev <misha.zaytsev.rus@gmail.com>
Date: Fri, 27 Jan 2017 00:35:36 +0300
Message-ID: <CABPQr27tFPL7qpB3JHz=z6i7Og0eeW6jigVuQDrLsGFxtV=HVQ@mail.gmail.com>
To: "jouni.nospam" <jouni.nospam@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c1cdb0a4a0c8d0547062180
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/Y2u7sWts9MktOaqKkQmwSTerNRQ>
Cc: 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: Thu, 26 Jan 2017 21:35:42 -0000

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
>