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

[Steve Donovan <[e-mail]>]

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 <[e-mail] 
> <mailto:[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] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/dime
>     <https://www.ietf.org/mailman/listinfo/dime>
>
>
>
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime