Re: [Dime] New version of DOIC rate draft

["Gunn, Janet P (NONUS)" <[e-mail]>]

Just addressing the first point- deleted the rest

-----Original Message-----
From: DiME <[e-mail]> On Behalf Of Ben Campbell
Sent: Saturday, September 15, 2018 7:57 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [Dime] New version of DOIC rate draft

Substantive Comments:

- General: I still think more discussion is needed about allocating rate to multiple input sources. I get that the actual allocation is a matter of local policy, but there’s still implications that need discussion. I’m not sure I got my concern across in previous discussion, so here’s another attempt:

The issue I think needs elaboration on is how the offered load varies with the number of sources times the (average) rate per each source. That is, if the number of sources changes, the reacting node may need to change the rate limits assigned to each existing source.

As a hypothetical example, lets assume a reporting node wants to limit its entire offered load to 1000 tps. Further assume it has 10 active reacting nodes (all supporting the rate algorithm). Local policy is to allocate the rate limit equally across sources. So it sends an OLR to each of those clients to give it a rate limit of 100 tps. Now, if another 10 reacting nodes become active, it needs to reallocate the load across all 20, giving each a limit of 50 tps. Now, if some of those reacting nodes go off-line, or simply reduce their activity beneath the limit for an extended period of time, the reporting node may need to increase the allocation to the remaining nodes.

This is a fairly fundamental difference between rate and load; rate uses absolute numbers while load uses percentages.

<JPG> I am not sure if it is as fundamental a difference  as you think. (in both cases assuming each node has a relatively stable  load.)
If there are 10 active reacting nodes, it asks each node to reduce its traffic to  (say) 50%.
 If 10 more nodes become active, it will need to ask each node to reduce its traffic to 25%
If some of those nodes go offline, or reduce their traffic, it will increase the (percentage) allocation to each remaining node.

The "fundamental" difference is when each node has a fluctuating, unstable, load.
Under "load" a node which currently has a small load needs to cut its traffic by the SAME percentage as the node which currently has a large load.
Under "rate" a node which currently has a small load does NOT need to cut its load while the node which currently has a large load DOES need to cut its load.</JPG>



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.