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

[Misha Zaytsev <[e-mail]>]

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 <[e-mail]>:

> 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:[e-mail]] *On Behalf Of *Misha Zaytsev
> *Sent:* Thursday, January 26, 2017 4:36 PM
> *To:* jouni.nospam <[e-mail]>
> *Cc:* [e-mail]
> *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 <[e-mail]>:
>
> 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
> [e-mail]
> 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.
>