Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

[Janet P Gunn <[e-mail]>]

I thought I understood that the point of this rate based algorithm ID  was 
to "piggy back" on the communications  protocol parameters defined in the 
loss based algorithm ID (oc, oc-algo, oc-num, oc-validity, oc-seq), 
introducing new parameter VALUES, but not new parameters.

In order to convey the "current arrival rate of messages intended for you" 
from the client to the server, you would need to add new parameters,  or 
use existing parameters in a way that would cause problems for  the loss 
based version.

Furthermore, when the client is receiving, and therefore sending, messaged 
intended for this server, at a rate lower than the current specified rate 
limit, the server can deduce that directly, and adjust the specific rate 
limit it sends to (this or other) clients if it wants to.

I think that would be much "cleaner" (and probably more effective as 
well), than adding new parameters, or making major changes to the 
communications protocol in the loss based algorithm ID.

Janet



[e-mail] wrote on 07/10/2013 09:00:35 AM:

> From: "Yu, James" <[e-mail]>
> To: "NOEL, ERIC C (ERIC C)" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>,
> "[e-mail]" <draft-
> [e-mail]>, "sip-
> [e-mail]" <[e-mail]>
> Date: 07/10/2013 09:01 AM
> Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt
> Sent by: [e-mail]
> 
> Noel,
> 
> I mentioned in my message to Janet on 7/2:
> 
> For the rate control, the server could calculate the arrival rate 
> from each communicating client so that it could allocate the overall
> target SIP request rate to the clients based on their arrival rates 
> known to the server.  But another option is for the client to 
> “optionally” include its calculated arrival rate in its request to 
> the server when rate control related parameters are present.  Should
> this option be evaluated/included to relieve the server from doing 
> the arrival rate calculations.  This would be beneficial to a server
> when it receives the requests from many clients.
> 
> I suggest that the I-D adds that option to allow the client to 
> indicate its current arrival rate (towards the receiving server) in 
> the SIP request.
> 
> James
> 
> From: NOEL, ERIC C (ERIC C) [mailto:[e-mail]] 
> Sent: Tuesday, July 09, 2013 4:44 PM
> To: Yu, James; Janet P Gunn
> Cc: [e-mail]; draft-ietf-soc-overload-rate-
> [e-mail]; [e-mail]
> Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt
> 
> Janet, James,
> 
> Thanks you for your valuable comments and discussion.  I tried to 
> capture all resolution in the following text (based on James word 
> document with track changes and imbedded comments enabled).
> 
> + Abstract section: 
> - Agreed with suggested changes
> - Please note I will also need to make further changes to remove all
> references per Christer Holmberg comment
> 
> + Section 1:
> - Agreed with suggested changes
> 
> + Section 3.1:
> - Agreed with suggested changes
> 
> + Section 3.2: - Please note the section title will become “Via 
> header field parameters for overload control “ per Christer Holmberg 
comment
> - Agreed with suggested changes excluding title that will change per
> previous bullet
> 
> + Section 3.3:
> - Agreed with suggested changes
> 
> + Section 3.4:
> - ID:  "Note that the target SIP request rate is a max rate that may
> not be attained by the arrival rate at the client, and the server 
> cannot assume that it will." 
>    [JY] Not clear what value this paragraph tries to add.  Is it 
> saying that the client's arrival rate may be lower than the target 
> SIP request rate? 
>    [JG] Yes + supporting example (see below in thread)
>   Agreed with Janet and supporting example. Per James request, I 
> will add the following text (inspired from Janet’s illustrative 
example):
>    “In other words, when multiple clients are being controlled by an
> overloaded server, at any given time some clients may receive 
> requests at a rate below its target SIP request rate while others 
> above that target rate. But the resulting request rate presented to 
> the overloaded server will converge towards the target SIP request 
rate.”
> - Agreed with other suggested changes 
> 
> + Section 3.5.1:
> - ID: “And the larger the difference between TAU1 and TAU2, the 
> closer to the control is to strict priority.”
>   [JY] Suggest changing into “And the larger the difference between 
> TAU1 and TAU2, the closer the control is to strict priority queuing.”
>   [JG] Suggest changing into “And the larger the difference between 
> TAU1 and TAU2, the closer the control is to strict priority treatment.”
>   [EN] Agreed with Janet’s suggestion
> - Agreed with other suggested changes
> 
> + Section 4:
> - Agreed with suggested changes
> 
> + Section 5:
> - Please note that based comments from per Christer Holmberg and 
> Janet Gunn, the following was tentatively agreed 
>    Replace oc-value = "NaN" / oc-num    by    oc = "oc" [EQUAL oc-num]
> - Agreed with other suggested change
> 
> + Section 7:
> - [JY] Should “rate” in oc-algo be registered with IANA?
>   This issue needs to be addressed by draft-ietf-soc-overload-control 
authors
> 
> Please note I will wait until expiration of WGLC prior updating our 
> draft RFC. Once again your comments and/or suggestions are most 
appreciated.
> 
> Thanks,
> 
> Eric Noel 
> AT&T Labs, Inc. 
> Rethink Possible
> 
> Network Design and Performance Analysis
> 200 South Laurel Avenue, D5-3D19
> Middletown, NJ 07748
> P: 732.420.4174
> [e-mail]
> 
> From: [e-mail] [
mailto:[e-mail]] 
> On Behalf Of Yu, James
> Sent: Tuesday, July 02, 2013 9:42 AM
> To: Janet P Gunn
> Cc: [e-mail]; draft-ietf-soc-overload-rate-
> [e-mail]; [e-mail]
> Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt
> 
> Janet,
> 
> For my comment on section 3.4 (the first one below), the current 
> text does not provide any value.  The client’s arrival rate could be
> well below the target SIP request rate when its load is light so the
> fact that the client may not achieve the target SIP request rate 
> (the max. rate it is allowed to send to the server) is well 
> understood.  But with your explanation on the “delta” part, the text
> then makes sense.  Please add some discussions on the “delta” aspect
> so that even if the average arrival rate at the client is higher 
> than the target SIP request rate the client at times may not send 
> more than what the target SIP request rate allows due to the 
> fluctuation of the arriving requests at the client.
> 
> For the comment on section 3.5.1, I agree with your proposed change.
> 
> For the rate control, the server could calculate the arrival rate 
> from each communicating client so that it could allocate the overall
> target SIP request rate to the clients based on their arrival rates 
> known to the server.  But another option is for the client to 
> “optionally” include its calculated arrival rate in its request to 
> the server when rate control related parameters are present.  Should
> this option be evaluated/included to relieve the server from doing 
> the arrival rate calculations.  This would be beneficial to a server
> when it receives the requests from many clients.
> 
> James
> 
> From: Janet P Gunn [mailto:[e-mail]] 
> Sent: Friday, June 28, 2013 3:34 PM
> To: Yu, James
> Cc: [e-mail]; sip-
> [e-mail]; [e-mail]
> Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt
> 
> James, 
> 
> It is a little hard to respond in email when your comments are in a 
> separate document, but here goes. 
> 
> 
> section 3.4 
> ID says: 
> "Note that the target SIP request rate is a max rate that may not be 
>    attained by the arrival rate at the client, and the server cannot 
>    assume that it will." 
> 
> Your comment : 
> "Not clear what value this paragraph tries to add.  Is it saying 
> that the client's arrival rate may be lower than the target SIP 
> request rate?  " 
> 
> Yes. 
> 
> Suppose the server want to limit the total rate of arriving SIP 
> messages to 100 / sec, and has 10 clients.  Each client has a high 
> variance in its message rate, but together they are well above 100 
> messages per sec 
> 
> If it sets the rate at 10 messages per second for each of the 
> clients, it will almost certainly end up  with an overall average of
> less than 100 messages per sec, because some clients will be in a 
> "lull" while others are busy.  This is good from a throttling 
> perspective, but, assuming messages are correlated with revenue, 
> bad/wasteful from a revenue, or overall productivity perspective. 
> So the server might want to set the rate per client to 10 + delta, 
> where delta is going to be very specific to operating environment. 
> 
> --- 
> In section  3.5.1, bottom of page 8 
> ID says: 
> "And the larger 
>    the difference between TAU1 and TAU2, the closer to the control is 
>    to strict priority." 
> 
> You propose changing it to: 
> "And the larger 
>    the difference between TAU1 and TAU2, the closer  the control is 
>    to strict priority queuing." 
> 
> I agree with taking out the redundant "to".  But I disagree wit 
> adding "queuing".  There is no queuing, priority or otherwise involved. 
> 
> You could say: 
> "And the larger 
>    the difference between TAU1 and TAU2, the closer  the control is 
>    to strict priority treatment." 
> 
> where " strict priority treatment" would refer to the case where 
> non-priority messages are restricted to a total (priority + non-
> priority) rate of 10 messages per second, but priority messages can 
> continue to be sent as long as the total (priority + non-priority) 
> rate is less than 12 messages per second. 
> 
> At least, I think that is what Eric and  Philip are trying to say. 
> 
> Janet 
> 
> 
> 
> 
> 
> This is a PRIVATE message. If you are not the intended recipient, 
> please delete without copying and kindly advise us by e-mail of the 
> mistake in delivery. NOTE: Regardless of content, this e-mail shall 
> not operate to bind CSC to any order or other contract unless 
> pursuant to explicit written agreement or government initiative 
> expressly permitting the use of e-mail for such purpose. 
> 
> 
> 
> From:        "Yu, James" <[e-mail]> 
> To:        "[e-mail]" 
<[e-mail]>, "
> [e-mail]" <draft-
> [e-mail]>, 
"[e-mail]" <
> [e-mail]> 
> Date:        06/28/2013 08:10 AM 
> Subject:        [sip-overload] 
draft-ietf-soc-overload-rate-control-04.txt 
> Sent by:        [e-mail] 
> 
> 
> 
> 
> Salvatore, 
> 
> Please see the attachment for my comments. 
> 
> I pasted the text to a word document to trace/show the proposed 
> changes and comments. 
> 
> Regards, 
> 
> James 
>  [attachment "comments on draft-ietf-soc-overload-rate-
> control-04.docx" deleted by Janet P Gunn/USA/CSC] 
> _______________________________________________
> sip-overload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload
> 
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 
06/30/13
> 
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 
07/09/13
> _______________________________________________
> sip-overload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload