Re: [Dime] draft-ietf-dime-doic-rate-control-08

["NOEL, ERIC C" <[e-mail]>]

Hi Steve,

All looks good. Many thanks for following through,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Optimization, Reliability and Customer Analytics
200 South Laurel Avenue, D5-3C38
Middletown, NJ 07748
P: 732.420.4174
[e-mail]<mailto:[e-mail]>

From: Steve Donovan [mailto:[e-mail]]
Sent: Monday, September 10, 2018 4:33 PM
To: NOEL, ERIC C <[e-mail]>; [e-mail]
Subject: Re: [Dime] draft-ietf-dime-doic-rate-control-08

Eric,

Thanks for the comments.  See my comments inline.

I will be submitting a new version of the document shortly.  Hopefully I have captured all of the suggested changes.

Steve

On 8/8/18 5:05 PM, NOEL, ERIC C wrote:
>
> Hi Steve,
>
>
>
> It seems my mail system has been moving to spam your emails.
>
>
>
> Just noticed below while cleaning my spam folder, apologies for the
> lack of responses.
>
>
>
> Please see below.
>
>
>
>>>> General: The document seems inconsistent about whether rate
>>>> limits are only reported during overload conditions, or in
>>>> advance of overload conditions.
>>>>
>>>> <JPG> I think that would be "local policy" of the serving
>>>> (reporting) node, and independent of the protocol used to
>>>> communicate it.  I think most cases would be reactive, but I
>>>> can see situations where it could be proactive.<JPG>
>>> SRD> I agree with Janet, when the report is sent is very much
>>> local policy.  There is no reason to attempt to prevent proactive
>>> use of the rate mechanism.
>>
>> That’s fine with me, but a sentence or two to that effect would be
>> helpful. (On re-reading, I see where section 1 talks about
>> “approaching overload or overloaded”, but I assume neither of those
>> conditions are necessary?)

srd> I've added the following in section 5.5:

          Note: It is also possible for the reporting node to send overload
          reports with the rate algorithm indicated when the reporting node is
          not in an overloaded state.  This could be a strategy to proactively
          avoid entering into an overloaded state.  Whether to do so is
          up to local policy.
>>
>>>>
>>>> I’d like to see the need to allocate the rate limit across all
>>>> potential sources of traffic given some more emphasis. (Maybe a
>>>> sub-section of its own?)
>>>>
>>>> <JPG> I agree, but again I see that as "local policy" of the
>>>> serving (reporting) node. In particular, there may be reacting
>>>> nodes that do not support the rate abatement algorithm.<JPG>
>>> SRD> Again, I agree with Janet.  This is local policy and there
>>> may well be a mix of rate and loss if not all nodes support rate.
>>> I don't think it is appropriate to say that rate should be
>>> preferred over loss.  But maybe I'm missing your meaning on
>>> "allocate the rate limit”.
>>
>> Okay, but you still have to allocate the rate limit across all
>> sources that you apply the rate algorithm to, right? That is, the
>> total offered rate will be something like (average rate per source)
>> * (number of sources). Or am I misunderstanding something?
>
>
>
> <EN> Correct, the reporting node maintains an overload control state
> for each reacting node.
>
SRD> I've added the following to section 5.1:

          The rate OCS entery SHOULD include the rate allocated to each reacting note.

>
>
>
>
>>>> §1: - “ While this can effectively decrease the load handled by
>>>> the server, it does not directly address cases where the rate
>>>> of arrival of service requests increases quickly."
>>>>
>>>> I think it fails to address cases where the load changes
>>>> rapidly in either direction, right? At least, the following
>>>> text seems to say that.
>>>>
>>>> <JPG> I agree.  When there are rapid fluctuations in the
>>>> offered load, the "loss" algorithm errs both in  throttling TOO
>>>> MUCH when there is a dip in offered load, and throttling NOT
>>>> ENOUGH when there is a spike in offered load.<JPG>
>>> SRD> The text in section 1 talks about this already.  Is there a
>>> specific change being suggested?
>>
>> Section 1 talks about rapidly increasing load. Did I miss mention
>> of rapidly _decreasing_ load?
>
>
>
> <EN> Suggested edit:
>
>
>
> While this can effectively decrease the load handled by the
>
> server, it does not directly address cases where the rate of arrival
>
> of service requests _changes_increases quickly.  _For instance,_ if
> the service requests that
>
> result in Diameter transactions increase quickly then the loss
>
> algorithm cannot guarantee the load presented to the server remains
>
> below a specific rate level.  _The loss algorithm can be slow to_
>
> _protect the stability of reporting nodes when subjected with
> rapidly_
>
> _changing loads. The "loss" algorithm errs both in throttling TOO
> MUCH _
>
> _when there is a dip in offered load, and throttling NOT ENOUGH when
> there _
>
> _is a spike in offered load._
>
>
SRD> I've incorporated Eric's suggested wording.
>
>
>
>>>> §3: Does the need for future report types to consider the rate
>>>> algorithm have IANA implications?
>>> SRD> Are you suggesting that the IANA section indicate that all
>>> new report types MUST indicate whether or not the rate algorithm
>>> can be used with that report type?  I can make that change to the
>>> IANA section if it would be appropriate.
>>>>
>>
>> I’m not suggesting, I’m asking :-)  But my point was more along
>> whether the IANA registry for report types should include a field
>> about supporting the rate algorithm.
>
> <EN> Not sure how to address that comment.

SRD> I've added a section the to the IANA considerations section:

8.2.   New DOIC Report Types

          All DOIC report types defined in the future MUST
          indicate whether or not the rate algorithm can be used with that
          report type.

>
>
>>>> §5.1: The first paragraph indicates state should be kept for
>>>> every reacting node to which it sends an OLR. But the 5th
>>>> paragraph can be interpreted to say it sends an OLR to every
>>>> reacting node with which it has negotiated use of the rate
>>>> algorithm. (see general comment).
>>> SRD> I'm missing something.  The first paragraph says the
>>> reporting node maintains state any time it sends a rate overload
>>> report.  The fifth paragraph is just saying that the report must
>>> include the rate information.
>>
>> Actually, my question relates to my question on 5.4. The first
>> paragraph says to keep state for every reporting node to which it
>> sends an OLR. The 5th paragraph implies that it sends on OLR when
>> it selects the rate algorithm for a reacting node. (If you are
>> going to include the rate info, you have to have a report to
>> include it in.)
>>
>> So it comes down to clarity about what events happen “when the
>> reporting node selects the algorithm for a reacting node” vs “when
>> the reporting node sends an OLR”.
>>
>>>>
>>>> §5.4: The first paragraph seems to suggest the reacting node
>>>> keeps OCS for every server that has indicated support for the
>>>> rate algorithm, not just nodes that have sent OLRs. Is that the
>>>> intent?
>>> SRD>  Yes, that is the intent.  This allows the reacting node to
>>> make sure that the machinery needed to respond to a rate request
>>> is in place prior to receiving an OLR.
>>
>> See above.
>
> <EN> Agreed. Do not know what does ‘see above’ refers to.

SRD> I don't see the need for a change to the document.  If there is still confusion then it can be addressed in the next version of the document.

>
>>>> §5.6, first paragraph: The MAY seems week here. I know and
>>>> agree that we don’t want to force a particular application. But
>>>> don’t we need to say that if an implementation uses a different
>>>> algorithm, it MUST have the same behavior as the algorithm in
>>>> section 7?
>>>>
>>>> <JPG> I think it MUST "limit the message rate to the
>>>> OC-Maximum-Rate AVP value in units of messages per second" (as
>>>> stated in 7.3.1).  The algorithm described in the rest of 7.3.1
>>>> and 7.3.2 is somewhat more sophisticated, allowing for a
>>>> smoothing factor (TAU) and prioritization.  I do not think we
>>>> need  to say that the selected algorithm MUST have those
>>>> features.<JPG>
>>> SRD> Again, I agree with Janet.
>>
>> Okay.
>
> <EN> Agreed.
>
>
>>>> §7.2, third and 4th paragraphs: I don’t understand what this is
>>>> trying to say. Please elaborate.
>>>>
>>>> <JPG>3rd para - Just as a "for instance"- if the reacting node
>>>> has 50/second low priority messages and 50/second high priority
>>>> messages that it want to send, and has a rate limit of
>>>> 75/second, it will send 25/second low priority messages and 50
>>>> /second high priority messages.  The limit of 75/second applies
>>>> to the combined stream of high and low priority messages, even
>>>> though only the low priority messages are being abated.<JPG >
>>>>
>>>> <JPG> 4th para - in the same example, it could be that the high
>>>> priority messages typically require more processing resources
>>>> (cpu, etc) than the low priority messages (or vice versa).  So
>>>> cutting the rate to 75/sec may NOT produce the expected
>>>> reduction in resource usage.<JPG>
>>> SRD> Thanks Janet, I couldn't have explained it better.
>>
>> Janet’s explanation is good, but I don’t get that from the text, at
>> least in the case of the third paragraph.
>>
>> In the 4th paragraph, I don’t understand how the reporting node
>> would “take into account the workload” in a useful way. That seems
>> to suggest the reporting node can predict the impact of workload
>> based decisions made by the reacting node, which seems unlikely
>> unless there is some out-of-band agreement.
>>
>> Is this really saying anything more than “The reacting nodes will
>> decide which messages to send and which to drop, and the result may
>> not be predictable by the reporting node”?
>
> <EN>  Computation of maximum rate per reacting node modulated with
> its measured workload (message type frequency) improves throttling
> when reacting nodes prioritize messages.
>
>>>> -6th paragraph: “  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.”
>>>>
>>>> Why do we expect traffic to converge to the rate limit? It
>>>> seems like that won't happen if some reporting nodes are not
>>>> sending at full capacity, unless work can be shifted from the
>>>> high-rate sources to the slow-rate ones.
>>>>
>>>> <JPG> Probably would be better to say that it "will converge
>>>> toward a rate at or below the target Diameter request
>>>> rate.”<JPG>
>>> SRD> I'm okay with making Janet's suggested change.
>>
>> WFM.
>
> <EN>  Agreed.
>
>>>> §7.3.1: paragraph starting with “ In situations where reacting
>>>> nodes are configured with some knowledge”
>>>>
>>>> that requires knowledge of other traffic sources, not just
>>>> knowledge of the reporting node.
>>>>
>>>> The example code says to transmit a message if (Xp <= TAU). But
>>>> the text said the limit was “T+TAU).
>>>>
>>>> <JPG> I think it is supposed to be "T+TAU"<JPG>
>>> SRD> I'd like to get Eric's opinion on this.  This section was
>>> copied from the SOC RFC so if it is in error here than it is in
>>> error there as well.
>>
>> I agree with getting Eric’s opinion :-)
>
> <EN>  Went back to IETF document  Xp <= TAU is correct (continuous
> state leaky bucket)
>
>>>> §9: I think the security considerations need more thought. What
>>>> are the security considerations specific to the rate algorithm?
>>>> If there aren’t any, then please describe the rational behind
>>>> that. But I suspect there are, for example, can this be used
>>>> for a DoS? Can it be used to help _mitigate_ a DoS? Could one
>>>> reacting node cause others to be traffic starved?
>>>>
>>>> <JPG>It is possible that a reacting node that does not support
>>>> overload control could starve the nodes that do support
>>>> overload control, but this is also true of the loss based
>>>> version<JPG>
>>> SRD> I'm not convinced that there are security scenarios that are
>>> new or different for rate versus those documented in the existing
>>> DOIC specifications.
>>
>> This draft adds a new feature that isn’t in the base mechanism. I
>> gather your point is to say that the new feature shares the same
>> security considerations as the base, and adds no new ones. Right
>> now, section 9 only states the former.
>
> <EN>  Computation
>
>>>> Editorial Comments:
>>>>
>>>> General: IDNits returns several issues. Some of those may be
>>>> errors on its part, but I’m pretty sure some of them are real.
>>>> Please resolve these.
>>> SRD> I'll look at those next time I try to submit but I've not
>>> gotten IDNits errors in the past.
>>>
>>> SRD> I've made the suggested changes below unless indicated
>>> otherwise.
>>>>
>>
>> … and I’ve deleted sections that seem resolved.
>>
>> […]
>
> <EN>  I think comment resolved
>
>>>> §5.1, third paragraph: The text is not clear whether this means
>>>> OCS should be maintained per supported application, etc, or
>>>> that it should maintain state when the rate algorithm on a per
>>>> supported application, etc, basis.
>>> SRD> I don't understand the point being made here.
>>
>> Probably because I failed to make it.
>>
>> I _think_ that the reporting node keeps state for each reporting
>> node for which it selects rate, and further needs to subdivide that
>> state by application and report type. But the it doesn’t need to
>> keep state for a reporting node for which it doesn’t select rate,
>> even though that reporting node might have an application in common
>> with the first reporting node?
>>
>> […]
>
> <EN>  Reporting node maintain state for each reacting node that
> executes the rate algorithm.
>
>>>> §6.1.1, definition of " OLR_RATE_ALGORITHM”: Two periods at end
>>>> of sentence.
>>>>
>>> SRD> I am hesitant to change any of the test in section 7 given
>>> that it is taken from the SOC specification.  I would prefer that
>>> Eric comment on these proposed changes before including them in
>>> the next version.
>>
>> Makes sense.
>
> <EN>  Typo, please remove extra period
>
>>>> §7.1, 2nd paragraph: “ signal one another support for
>>>> rate-based overload control”: This seems awkward; are there
>>>> missing words?
>
> <EN>  Looks ok to me , but I am not an English native speaker.
>
>>>> §7.2, last two paragraphs: The MUSTs do not seem necessary.
>>>> 2119 keywords should be used when there is some sort of choice
>>>> or room for error. You don’t need them to define the basic
>>>> operation of the protocol.
>
> <EN>  OK with me
>
>>>> §7.3.1: I found the text hard to follow. It would help to
>>>> declare all the identifiers and initialization up front, and to
>>>> present things in more of a stepwise fashion.
>>>>
>>>> - T is effectively a time interval, right? It would help to say
>>>> that, especially later when you subtract a different time
>>>> interval from it.
>>>>
>>>> - paragraph 9: Should “admit” be “emit”?
>>>>
>>>> - the example code has several mentions of SIP requests.
>
> <EN>   T  = 1/[OC-Maximum-Rate] is the target inter-Diameter request
> interval  per 7.3.1 paragraph 1. “admit” usage is correct SIP should
> be replace with Diameter
>
>>>> §7.3.2: “ Request candidates for reduction, requests not
>>>> subject to reduction (except under extenuating circumstances
>>>> when there aren’t any messages in the first category that can
>>>> be reduced).”: That seems like an awkward way to say that the
>>>> second category is the set of requests that is only subject to
>>>> reduction if there are no messages left in the first category.
>>>>
>>>> <JPG> Yes, that is what it means.<JPG>
>>>>
>>>> - “ This can be generalized to n priorities using n thresholds
>>>> for n>2 in the obvious way.”: I suggest you refrain from
>>>> calling it “obvious".
>
> <EN>    Agreed
>
>>>> §7.3.3: Paragraph starting with “ Then (only) if the arrival is
>>>> admitted, increase the bucket by an amount…”: I think you
>>>> increase the bucket _count_, right?
>
>
>
> <EN>   Correct
>
>
>
> Thanks,
>
>
>
> Eric Noel
>
> *AT&T Labs, Inc.* /Rethink Possible/
>
>
>
> Optimization, Reliability and Customer Analytics
>
> 200 South Laurel Avenue, D5-3C38 Middletown, NJ 07748 P:
> 732.420.4174
>
> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>
>
>
>
> *From:*Steve Donovan [mailto:[e-mail]] *Sent:*
> Monday, August 06, 2018 12:42 PM *To:* NOEL, ERIC C <[e-mail]><mailto:[e-mail]>
> *Subject:* Fwd: Re: [Dime] draft-ietf-dime-doic-rate-control-08
>
>
>
> Eric,
>
> If not I will make the necessary changes.  I would prefer that you
> handle the comments on the actual rate algorithm but, if you are not
> able then I will make the necessary changes.
>
> Regards,
>
> Steve
>
>
>
> -------- Forwarded Message --------
>
> *Subject: *
>
>
>
> Re: [Dime] draft-ietf-dime-doic-rate-control-08
>
> *Date: *
>
>
>
> Tue, 26 Jun 2018 16:08:56 -0500
>
> *From: *
>
>
>
> Ben Campbell <[e-mail]><mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>
>
> *To: *
>
>
>
> Steve Donovan <[e-mail]><mailto:[e-mail]>
> <mailto:[e-mail]><mailto:[e-mail]>
>
> *CC: *
>
>
>
> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>,
> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>
>
>
>
> <bump>
>
>> On Jun 14, 2018, at 4:38 PM, Ben Campbell <[e-mail]><mailto:[e-mail]>
>> <mailto:[e-mail]><mailto:[e-mail]> wrote:
>>
>> Hi,
>>
>> See my responses inline. I removed sections that seem resolved.
>>
>> Thanks,
>>
>> Ben.
>>
>>> On Jun 13, 2018, at 12:30 PM, Steve Donovan
>>> <[e-mail]><mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>
>>> wrote:
>>>
>>> See my comments inline.
>>>
>>> Steve
>>>
>>> On 5/25/18 4:17 PM, Gunn, Janet P (CNV) wrote:
>>>> Not an author, but I have a strong interest in this ID.
>>>> Comments in line. Janet
>>>>
>>>> -----Original Message----- From: DiME <[e-mail]><mailto:[e-mail]>
>>>> <mailto:[e-mail]><mailto:[e-mail]> On Behalf Of Ben Campbell Sent:
>>>> Wednesday, May 16, 2018 1:31 AM To:
>>>> [e-mail]<mailto:[e-mail]>
>>>> <mailto:[e-mail]><mailto:[e-mail]> Cc:
>>>> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]> Subject: [Dime]
>>>> draft-ietf-dime-doic-rate-control-08
>>>>
>>>> Substantive Comments:
>>>>
>>>> General: The document seems inconsistent about whether rate
>>>> limits are only reported during overload conditions, or in
>>>> advance of overload conditions.
>>>>
>>>> <JPG> I think that would be "local policy" of the serving
>>>> (reporting) node, and independent of the protocol used to
>>>> communicate it.  I think most cases would be reactive, but I
>>>> can see situations where it could be proactive.<JPG>
>>> SRD> I agree with Janet, when the report is sent is very much
>>> local policy.  There is no reason to attempt to prevent proactive
>>> use of the rate mechanism.
>>
>> That’s fine with me, but a sentence or two to that effect would be
>> helpful. (On re-reading, I see where section 1 talks about
>> “approaching overload or overloaded”, but I assume neither of those
>> conditions are necessary?)
>>
>>>>
>>>> I’d like to see the need to allocate the rate limit across all
>>>> potential sources of traffic given some more emphasis. (Maybe a
>>>> sub-section of its own?)
>>>>
>>>> <JPG> I agree, but again I see that as "local policy" of the
>>>> serving (reporting) node. In particular, there may be reacting
>>>> nodes that do not support the rate abatement algorithm.<JPG>
>>> SRD> Again, I agree with Janet.  This is local policy and there
>>> may well be a mix of rate and loss if not all nodes support rate.
>>> I don't think it is appropriate to say that rate should be
>>> preferred over loss.  But maybe I'm missing your meaning on
>>> "allocate the rate limit”.
>>
>> Okay, but you still have to allocate the rate limit across all
>> sources that you apply the rate algorithm to, right? That is, the
>> total offered rate will be something like (average rate per source)
>> * (number of sources). Or am I misunderstanding something?
>>
>>
>>>>
>>>>
>>>> §1: - “ While this can effectively decrease the load handled by
>>>> the server, it does not directly address cases where the rate
>>>> of arrival of service requests increases quickly."
>>>>
>>>> I think it fails to address cases where the load changes
>>>> rapidly in either direction, right? At least, the following
>>>> text seems to say that.
>>>>
>>>> <JPG> I agree.  When there are rapid fluctuations in the
>>>> offered load, the "loss" algorithm errs both in  throttling TOO
>>>> MUCH when there is a dip in offered load, and throttling NOT
>>>> ENOUGH when there is a spike in offered load.<JPG>
>>> SRD> The text in section 1 talks about this already.  Is there a
>>> specific change being suggested?
>>
>> Section 1 talks about rapidly increasing load. Did I miss mention
>> of rapidly _decreasing_ load?
>>
>>>>
>>>>
>>>>
>>>> §3: Does the need for future report types to consider the rate
>>>> algorithm have IANA implications?
>>> SRD> Are you suggesting that the IANA section indicate that all
>>> new report types MUST indicate whether or not the rate algorithm
>>> can be used with that report type?  I can make that change to the
>>> IANA section if it would be appropriate.
>>>>
>>
>> I’m not suggesting, I’m asking :-)  But my point was more along
>> whether the IANA registry for report types should include a field
>> about supporting the rate algorithm.
>>
>>
>>>> §5.1: The first paragraph indicates state should be kept for
>>>> every reacting node to which it sends an OLR. But the 5th
>>>> paragraph can be interpreted to say it sends an OLR to every
>>>> reacting node with which it has negotiated use of the rate
>>>> algorithm. (see general comment).
>>> SRD> I'm missing something.  The first paragraph says the
>>> reporting node maintains state any time it sends a rate overload
>>> report.  The fifth paragraph is just saying that the report must
>>> include the rate information.
>>
>> Actually, my question relates to my question on 5.4. The first
>> paragraph says to keep state for every reporting node to which it
>> sends an OLR. The 5th paragraph implies that it sends on OLR when
>> it selects the rate algorithm for a reacting node. (If you are
>> going to include the rate info, you have to have a report to
>> include it in.)
>>
>> So it comes down to clarity about what events happen “when the
>> reporting node selects the algorithm for a reacting node” vs “when
>> the reporting node sends an OLR”.
>>
>>>>
>>>> §5.4: The first paragraph seems to suggest the reacting node
>>>> keeps OCS for every server that has indicated support for the
>>>> rate algorithm, not just nodes that have sent OLRs. Is that the
>>>> intent?
>>> SRD>  Yes, that is the intent.  This allows the reacting node to
>>> make sure that the machinery needed to respond to a rate request
>>> is in place prior to receiving an OLR.
>>
>> See above.
>>
>>
>>>>
>>>> §5.6, first paragraph: The MAY seems week here. I know and
>>>> agree that we don’t want to force a particular application. But
>>>> don’t we need to say that if an implementation uses a different
>>>> algorithm, it MUST have the same behavior as the algorithm in
>>>> section 7?
>>>>
>>>> <JPG> I think it MUST "limit the message rate to the
>>>> OC-Maximum-Rate AVP value in units of messages per second" (as
>>>> stated in 7.3.1).  The algorithm described in the rest of 7.3.1
>>>> and 7.3.2 is somewhat more sophisticated, allowing for a
>>>> smoothing factor (TAU) and prioritization.  I do not think we
>>>> need  to say that the selected algorithm MUST have those
>>>> features.<JPG>
>>> SRD> Again, I agree with Janet.
>>
>> Okay.
>>
>>
>>>>
>>>> §7.2, third and 4th paragraphs: I don’t understand what this is
>>>> trying to say. Please elaborate.
>>>>
>>>> <JPG>3rd para - Just as a "for instance"- if the reacting node
>>>> has 50/second low priority messages and 50/second high priority
>>>> messages that it want to send, and has a rate limit of
>>>> 75/second, it will send 25/second low priority messages and 50
>>>> /second high priority messages.  The limit of 75/second applies
>>>> to the combined stream of high and low priority messages, even
>>>> though only the low priority messages are being abated.<JPG >
>>>>
>>>> <JPG> 4th para - in the same example, it could be that the high
>>>> priority messages typically require more processing resources
>>>> (cpu, etc) than the low priority messages (or vice versa).  So
>>>> cutting the rate to 75/sec may NOT produce the expected
>>>> reduction in resource usage.<JPG>
>>> SRD> Thanks Janet, I couldn't have explained it better.
>>
>> Janet’s explanation is good, but I don’t get that from the text, at
>> least in the case of the third paragraph.
>>
>> In the 4th paragraph, I don’t understand how the reporting node
>> would “take into account the workload” in a useful way. That seems
>> to suggest the reporting node can predict the impact of workload
>> based decisions made by the reacting node, which seems unlikely
>> unless there is some out-of-band agreement.
>>
>> Is this really saying anything more than “The reacting nodes will
>> decide which messages to send and which to drop, and the result may
>> not be predictable by the reporting node”?
>>
>>
>>
>>>>
>>>>
>>>> -6th paragraph: “  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.”
>>>>
>>>> Why do we expect traffic to converge to the rate limit? It
>>>> seems like that won't happen if some reporting nodes are not
>>>> sending at full capacity, unless work can be shifted from the
>>>> high-rate sources to the slow-rate ones.
>>>>
>>>> <JPG> Probably would be better to say that it "will converge
>>>> toward a rate at or below the target Diameter request
>>>> rate.”<JPG>
>>> SRD> I'm okay with making Janet's suggested change.
>>
>> WFM.
>>
>>
>>>>
>>>> §7.3.1: paragraph starting with “ In situations where reacting
>>>> nodes are configured with some knowledge”
>>>>
>>>> that requires knowledge of other traffic sources, not just
>>>> knowledge of the reporting node.
>>>>
>>>> The example code says to transmit a message if (Xp <= TAU). But
>>>> the text said the limit was “T+TAU).
>>>>
>>>> <JPG> I think it is supposed to be "T+TAU"<JPG>
>>> SRD> I'd like to get Eric's opinion on this.  This section was
>>> copied from the SOC RFC so if it is in error here than it is in
>>> error there as well.
>>
>> I agree with getting Eric’s opinion :-)
>>
>>
>>>>
>>>> §9: I think the security considerations need more thought. What
>>>> are the security considerations specific to the rate algorithm?
>>>> If there aren’t any, then please describe the rational behind
>>>> that. But I suspect there are, for example, can this be used
>>>> for a DoS? Can it be used to help _mitigate_ a DoS? Could one
>>>> reacting node cause others to be traffic starved?
>>>>
>>>> <JPG>It is possible that a reacting node that does not support
>>>> overload control could starve the nodes that do support
>>>> overload control, but this is also true of the loss based
>>>> version<JPG>
>>> SRD> I'm not convinced that there are security scenarios that are
>>> new or different for rate versus those documented in the existing
>>> DOIC specifications.
>>
>> This draft adds a new feature that isn’t in the base mechanism. I
>> gather your point is to say that the new feature shares the same
>> security considerations as the base, and adds no new ones. Right
>> now, section 9 only states the former.
>>
>>>>
>>>> Editorial Comments:
>>>>
>>>> General: IDNits returns several issues. Some of those may be
>>>> errors on its part, but I’m pretty sure some of them are real.
>>>> Please resolve these.
>>> SRD> I'll look at those next time I try to submit but I've not
>>> gotten IDNits errors in the past.
>>>
>>> SRD> I've made the suggested changes below unless indicated
>>> otherwise.
>>>>
>>
>> … and I’ve deleted sections that seem resolved.
>>
>> […]
>>
>>
>>>>
>>>> §5.1, third paragraph: The text is not clear whether this means
>>>> OCS should be maintained per supported application, etc, or
>>>> that it should maintain state when the rate algorithm on a per
>>>> supported application, etc, basis.
>>> SRD> I don't understand the point being made here.
>>
>> Probably because I failed to make it.
>>
>> I _think_ that the reporting node keeps state for each reporting
>> node for which it selects rate, and further needs to subdivide that
>> state by application and report type. But the it doesn’t need to
>> keep state for a reporting node for which it doesn’t select rate,
>> even though that reporting node might have an application in common
>> with the first reporting node?
>>
>> […]
>>
>>
>>>>
>>>> §6.1.1, definition of " OLR_RATE_ALGORITHM”: Two periods at end
>>>> of sentence.
>>>>
>>> SRD> I am hesitant to change any of the test in section 7 given
>>> that it is taken from the SOC specification.  I would prefer that
>>> Eric comment on these proposed changes before including them in
>>> the next version.
>>
>> Makes sense.
>>
>>>> §7.1, 2nd paragraph: “ signal one another support for
>>>> rate-based overload control”: This seems awkward; are there
>>>> missing words?
>>>>
>>>> §7.2, last two paragraphs: The MUSTs do not seem necessary.
>>>> 2119 keywords should be used when there is some sort of choice
>>>> or room for error. You don’t need them to define the basic
>>>> operation of the protocol.
>>>>
>>>> §7.3.1: I found the text hard to follow. It would help to
>>>> declare all the identifiers and initialization up front, and to
>>>> present things in more of a stepwise fashion.
>>>>
>>>> - T is effectively a time interval, right? It would help to say
>>>> that, especially later when you subtract a different time
>>>> interval from it.
>>>>
>>>> - paragraph 9: Should “admit” be “emit”?
>>>>
>>>> - the example code has several mentions of SIP requests.
>>>>
>>>> §7.3.2: “ Request candidates for reduction, requests not
>>>> subject to reduction (except under extenuating circumstances
>>>> when there aren’t any messages in the first category that can
>>>> be reduced).”: That seems like an awkward way to say that the
>>>> second category is the set of requests that is only subject to
>>>> reduction if there are no messages left in the first category.
>>>>
>>>> <JPG> Yes, that is what it means.<JPG>
>>>>
>>>> - “ This can be generalized to n priorities using n thresholds
>>>> for n>2 in the obvious way.”: I suggest you refrain from
>>>> calling it “obvious".
>>>>
>>>> §7.3.3: Paragraph starting with “ Then (only) if the arrival is
>>>> admitted, increase the bucket by an amount…”: I think you
>>>> increase the bucket _count_, right?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 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.
>>>> _______________________________________________ DiME mailing
>>>> list [e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/dime<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dime&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=SKkl9o9SIAeqd7FMlTEbQQ&m=UibRRRVW7rkRT3DUGwGwbauOt9s4BWEwCrGXKEcraBE&s=gsOe8rkPMVdmrlkxfNHyVCsFW3UxmsXEzdd3qHPBvI8&e=>
>>>
>>> _______________________________________________ DiME mailing
>>> list [e-mail]<mailto:[e-mail]> <mailto:[e-mail]><mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/dime<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dime&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=SKkl9o9SIAeqd7FMlTEbQQ&m=UibRRRVW7rkRT3DUGwGwbauOt9s4BWEwCrGXKEcraBE&s=gsOe8rkPMVdmrlkxfNHyVCsFW3UxmsXEzdd3qHPBvI8&e=>
>>
>>
>>
>
>