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

From: "Gunn, Janet P" <[email-masked]>
Date: Wed, 1 Feb 2017 19:57:20 +0000

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:[email-masked]] On Behalf Of Misha Zaytsev
Sent: Thursday, January 26, 2017 4:36 PM
To: jouni.nospam <[email-masked]>
Cc: [email-masked]
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 (0x000000000000000100)

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 <[email-masked]<mailto:[email-masked]>>:
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
[email-masked]<mailto:[email-masked]>
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.

---

From: Misha Zaytsev <[email-masked]>
Date: Wed, 1 Feb 2017 23:30:47 +0300

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 <[email-masked]>:

> Loss algorithm is about the case with a specific traffic rate. Thus, the
> amount of the abated traffic directly depends on its rate.
>
> 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""
>
>
>
> 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
>
> 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)
>
> - 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:[email-masked]] *On Behalf Of *Misha Zaytsev
> *Sent:* Thursday, January 26, 2017 4:36 PM
> *To:* jouni.nospam <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Dime] WGLC #3 for draft-ietf-dime-doic-rate-control-04
>
>
>
> Hi,
>
>
>
> If the service requests that result in Diameter transactions *increase *quickly...
>
>
>
> Consider the case where a reacting *(?)* node is handling 100 service
>
>    one Diameter transaction being sent to a *reporting *node.  If the
>
>    *reporting *node is approaching an overload state, or is already in an
>
>    will then abate (diverting or throttling) ten Diameter transactions *per*
>
>    *reporting *node.
> The reacting node will continue to honor the *reporting node's request* for a 10% reduction in traffic.
>
>
>
> 4. section 1, question
>
>
>
> Loss algorithm is about the case with a specific traffic rate. Thus, the
> amount of the abated traffic directly depends on its rate.
>
> 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"
>
>
>
> 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
>
>
>
>    [I-D.ietf-dime-agent-overload] *are applied*.
>
>
>
> 9. section 6.1.1
>
>
>
> OLR_RATE_ALGORITHM (0x000000000000000*100*)
>
>
>
> 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.
>
> 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
>
>
>
> 2017-01-23 4:27 GMT+03:00 jouni.nospam <[email-masked]>:
>
> Folks,
>
> [email-masked]
> 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.
>

---

From: "Gunn, Janet P" <[email-masked]>
Date: Wed, 1 Feb 2017 20:34:19 +0000

OK.
We are in agreement about what it MEANS, and we can let the author figure out the best "short and simple" way to describe it.

Janet

From: Misha Zaytsev [mailto:[email-masked]]
Sent: Wednesday, February 01, 2017 3:31 PM
To: Gunn, Janet P <[email-masked]>
Cc: jouni.nospam <[email-masked]>; [email-masked]
Subject: Re: [Dime] WGLC #3 for draft-ietf-dime-doic-rate-control-04

Hi Janet,

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 <[email-masked]<mailto:[email-masked]>>:
I agree with most of Misha's comments.

Janet
From: DiME [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Misha Zaytsev
Sent: Thursday, January 26, 2017 4:36 PM
To: jouni.nospam <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] WGLC #3 for draft-ietf-dime-doic-rate-control-04

Hi,

1. section 1.

   reporting node.

4. section 1, question

5. section 5.1/general

6. section 5.5./general

7. section 5.5

   be included.

8. section 5.6

9. section 6.1.1

   traffic.

11. section 7.1

12. section 7.2

   abatement is in effect.

   to each of its clients.

   abatement mechanism.

Best regards,

/Misha

Regards,
        Jouni

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 1 Feb 2017 20:34:42 +0000

For a storm surge of messages the rate control is much better, loss can't handle it according to our modeling

Regards

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360<tel:+1.609.903.3360>
Email: [email-masked]<mailto:[email-masked]>

On Feb 1, 2017, at 3:31 PM, Misha Zaytsev <[email-masked]<mailto:[email-masked]>> wrote:

Hi Janet,

/Misha

Janet

Hi,

1. section 1.

   reporting node.

4. section 1, question

5. section 5.1/general

6. section 5.5./general

7. section 5.5

   be included.

8. section 5.6

9. section 6.1.1

   traffic.

11. section 7.1

12. section 7.2

   abatement is in effect.

   to each of its clients.

   abatement mechanism.

Best regards,

/Misha

Regards,
        Jouni

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Thu, 2 Feb 2017 14:29:21 -0600

Version -04 addresses all my comments that I made during the previous 
WGLC. I still support the draft.

Thanks!

Jean

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Fri, 3 Feb 2017 12:39:57 +0000

And AT&T supports this draft.

From: DOLLY, MARTIN C
Sent: Wednesday, February 01, 2017 3:35 PM
To: Misha Zaytsev <[email-masked]>
Cc: Gunn, Janet P <[email-masked]>; [email-masked]
Subject: Re: [Dime] WGLC #3 for draft-ietf-dime-doic-rate-control-04

Regards
Martin C. Dolly

/Misha

Janet

Hi,

1. section 1.

   reporting node.

4. section 1, question

5. section 5.1/general

6. section 5.5./general

7. section 5.5

   be included.

8. section 5.6

9. section 6.1.1

   traffic.

11. section 7.1

12. section 7.2

   abatement is in effect.

   to each of its clients.

   abatement mechanism.

Best regards,

/Misha

Regards,
        Jouni

---

From: "jouni.nospam" <[email-masked]>
Date: Mon, 6 Feb 2017 08:53:10 -0800

The WGLC has ended for this draft. There were few reviews, which is great. I’ll check the review comments and then decide on the next steps. 

Thank you for everyone who contributed.

- Jouni

> On Jan 22, 2017, at 5:27 PM, jouni.nospam <[email-masked]> wrote:
> 
> Folks,
>

---

From: Steve Donovan <[email-masked]>
Date: Thu, 16 Feb 2017 13:47:46 -0600

Misha,

Thanks for the review.

Please find my comments inline.

Regards,

Steve

On 1/26/17 3:35 PM, Misha Zaytsev wrote:
> If the service requests that result in Diameter transactions*increase *quickly...
>
SRD> Updated
> Consider the case where a reacting*(?)*  node is handling 100 service
>     one Diameter transaction being sent to a*reporting *node.  If the
>     will then abate (diverting or throttling) ten Diameter transactions*per*
SRD> Updated
> The reacting node will continue to honor the*reporting node's request*  for a 10% reduction in traffic.
>
SRD> Updated
> Loss algorithm is about the case with a specific traffic rate. Thus, 
> the amount of the abated traffic directly depends on its rate.
SRD> I think it is better to have the motivating text in this section.
> 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."
> DiameterID -> DiameterIdentity
SRD> Updated
> Rate algorithm -> rate algorithm (if not at the beginning of the 
SRD> Updated
> 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
>     [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.
> OLR_RATE_ALGORITHM (0x000000000000000*100*)
SRD> No, this is the hex representation of the field.
> 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.
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.
> They should not send more than the specified OC-Maximum-Rate value, right?
SRD> Correct
>     specification to communicate a target maximum Diameter request rate
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 
SRD> Updated
> As such, all of the security considerations outlined in [RFC7683] are applied to the rate overload
SRD> The original wording is correct.  Those considerations apply to 
this specifications.
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/dime>
>
>
>
>