Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt
"NOEL, ERIC C (ERIC C)" <ecnoel@research.att.com> Thu, 11 July 2013 18:32 UTC
Return-Path: <ecnoel@research.att.com>
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81FF21F9FF9; Thu, 11 Jul 2013 11:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BApa7MRVDWVm; Thu, 11 Jul 2013 11:32:46 -0700 (PDT)
Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id C79B221F9CD9; Thu, 11 Jul 2013 11:32:45 -0700 (PDT)
Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 3AB971206F5; Thu, 11 Jul 2013 14:32:44 -0400 (EDT)
Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-blue.research.att.com (Postfix) with ESMTP id 2DBC4F035E; Thu, 11 Jul 2013 14:32:45 -0400 (EDT)
Received: from njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%14]) with mapi; Thu, 11 Jul 2013 14:32:44 -0400
From: "NOEL, ERIC C (ERIC C)" <ecnoel@research.att.com>
To: "'DRAGE, Keith (Keith)'" <keith.drage@alcatel-lucent.com>, "'Yu, James'" <james.yu@neustar.biz>
Date: Thu, 11 Jul 2013 14:32:42 -0400
Thread-Topic: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt
Thread-Index: Ac5zhcqru7dYQFxqQKSGvvGKSQFJEAA0j1MAALOuppABZadV0AAr0zMgAAJGKhAAAUkxUAABlYhgAAIP6nAABdJLAAABh6NQAAMQj4AAK6QVgA==
Message-ID: <5EBD159DE88147488A3B1590E09001840353C068758D@njfpsrvexg2.research.att.com>
References: <56FB15AFE08E1242B0736CBDCE6E85610808C32F@stntexmb12.cis.neustar.com> <OF5E51912C.2DA069C7-ON85257B98.0069B365-85257B98.006B8697@csc.com> <56FB15AFE08E1242B0736CBDCE6E85610808EF90@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353BDA4CAD4@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E85610809239D@stntexmb12.cis.neustar.com> <56FB15AFE08E1242B0736CBDCE6E85610809253D@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687578@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092986@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C068757C@njfpsrvexg2.research.att.com> <56FB15AFE08E1242B0736CBDCE6E856108092BD9@stntexmb12.cis.neustar.com> <5EBD159DE88147488A3B1590E09001840353C0687581@njfpsrvexg2.research.att.com> <949EF20990823C4C85C18D59AA11AD8B06820F@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B06820F@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_5EBD159DE88147488A3B1590E09001840353C068758Dnjfpsrvexg2_"
MIME-Version: 1.0
Cc: "sip-overload-bounces@ietf.org" <sip-overload-bounces@ietf.org>, "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" <draft-ietf-soc-overload-rate-control.all@tools.ietf.org>, "sip-overload@ietf.org" <sip-overload@ietf.org>
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload <sip-overload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-overload>
List-Post: <mailto:sip-overload@ietf.org>
List-Help: <mailto:sip-overload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jul 2013 18:32:58 -0000
Keith, Thank you for your comment. IANA impacts: - Based on Keith suggestion, for the IANA impacts we only need to have the IANA consideration section in draft-ietf-soc-overload-control to include the future RFC number for draft-ietf-soc-overload-rate-control in the reference column - While James is suggesting explicitly defining the new parameter value in the IANA consideration section of draft-ietf-soc-overload-rate-control => Because Keith proposal is aligned with RFC 3968 guidelines, I propose adopting his proposal. ABNF impacts: - Based on Keith suggestion, draft-ietf-soc-overload-rate-control syntax section should be reduced to algo-list /= "rate" - While James is suggesting that section to include oc = "oc" [EQUAL oc-num] oc-num = 1*DIGIT oc-algo = "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE algo-list = "loss" / "rate" / *(other-algo) other-algo = %x41-5A / %x61-7A / %x30-39 => Per Keith suggestion, to prevent potential conflicts, I propose adopting his proposal. James would you agree with the proposed resolution? 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 ecnoel@att.com<mailto:jsmith@att.com> From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: Wednesday, July 10, 2013 6:05 PM To: NOEL, ERIC C (ERIC C); 'Yu, James' Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt I've lost track of what is happening here. What I expect is two things: 1) IANA registration impact. For the header field parameters registry, draft-ietf-soc-overload-control already creates the new rows: Header Field Parameter Name Predefined Values Reference __________________________________________________________ Via oc Yes RFCXXXX Via oc-validity Yes RFCXXXX Via oc-seq Yes RFCXXXX Via oc-algo Yes RFCXXXX RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of this specification.] For the predefined values columns, RFC 3968 states: Some SIP header field parameters only accept a set of predefined parameter values. For example, a parameter indicating the transport protocol in use may only accept the predefined tokens TCP, UDP, and SCTP as valid values. Registering all parameter values for all SIP header field parameters of this type would require a large number of subregistries. Instead, we have chosen to register parameter values by reference. That is, the entry in the parameter registry for a given header field parameter contains references to the RFCs defining new values of the parameter. References to RFCs defining parameter values appear in double brackets in the registry. So, the header field parameter registry contains a column that indicates whether or not each parameter only accepts a set of predefined values. Implementers of parameters with a "yes" in that column need to find all the valid parameter values in the RFCs provided as references. With this understanding, I do not believe the rate-control draft needs to modify the "predefined values" column. What it does need to do is add its ultimate RFC number to the reference column. There could be an argument that there needs to be a new table that lists the algorithm values, but a) if such a table is to be created, it needs to be created by draft-ietf-soc-overload-control rather than the rate-control draft/ b) I personally do not think it is necessary to add such a new table, as I think the references are sufficient. One cannot handle the algorithm values unless one goes to the relevant RFC. 2) ABNF impact. ABNF defines the /= operator for adding new values to an existing defined list. I do not think we should reproduce existing ABNF from draft-ietf-soc-overload-control and then amend it. The reason for this is that tools exist for automatically extracting the ABNF from RFCs. An extracted algo-list /= "rate" will work perfectly well with the extract from draft-ietf-soc-overload-control (and from SIP). Reproducing productions will result in conflict. Regards Keith ________________________________ From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of NOEL, ERIC C (ERIC C) Sent: 10 July 2013 20:54 To: 'Yu, James' Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, So section 5 (syntax) will include the following statements: oc = "oc" [EQUAL oc-num] oc-num = 1*DIGIT oc-algo = "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE algo-list = "loss" / "rate" / *(other-algo) other-algo = %x41-5A / %x61-7A / %x30-39 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 ecnoel@att.com<mailto:jsmith@att.com> From: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 3:10 PM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Eric, You may want to copy the "oc-algo" line from other I-D. James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Wednesday, July 10, 2013 1:10 PM To: Yu, James Cc: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, Based on your suggestion and comments from other reviewers, I intend to update section 5 (syntax) as follows: oc = "oc" [EQUAL oc-num] oc-num = 1*DIGIT algo-list = "loss" / "rate" / *(other-algo) other-algo = %x41-5A / %x61-7A / %x30-39 I understand there may be an additional change following Henning's reply. 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 ecnoel@att.com<mailto:jsmith@att.com> From: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 11:36 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org<mailto:sip-overload-bounces@ietf.org>; draft-ietf-soc-overload-rate-control.all@tools.ietf.org<mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>; sip-overload@ietf.org<mailto:sip-overload@ietf.org> Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Eric, Yes, this adds "rate" to "oc-algo" parameter but please check with IANA to see if it is the correct way. You also need to copy some syntax lines from the draft-ietf-soc-overload-control to show algo-list = "loss" / "rate" / *(other-algo) I've an email to Henning asking if algo-list in his I-D should be algo-list = "loss" / other-algo If yes, then this particular line in your I-D would be algo-list = "loss" / "rate" / other-algo James From: NOEL, ERIC C (ERIC C) [mailto:ecnoel@research.att.com] Sent: Wednesday, July 10, 2013 10:49 AM To: Yu, James Cc: sip-overload-bounces@ietf.org<mailto:sip-overload-bounces@ietf.org>; draft-ietf-soc-overload-rate-control.all@tools.ietf.org<mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>; sip-overload@ietf.org<mailto:sip-overload@ietf.org> Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt James, Thank you for your suggestion. Not being familiar with IANA procedure, would updating draft-ietf-soc-overload-rate-control section 7 (IANA considerations) as follows work? This specification defines a new value for Via header parameter oc-algo as detailed below in the "Header Field Parameter and Parameter Values" subregistry as per the registry created by [RFC3968]. The required information is: Header Field Parameter Name Predefined Values Reference ---------------------------------------------------------------------------------------------------------- Via oc-algo "rate" RFCXXXX RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of this specification.] 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 ecnoel@att.com<mailto:jsmith@att.com> From: Yu, James [mailto:james.yu@neustar.biz] Sent: Wednesday, July 10, 2013 10:17 AM To: NOEL, ERIC C (ERIC C) Cc: sip-overload-bounces@ietf.org<mailto:sip-overload-bounces@ietf.org>; draft-ietf-soc-overload-rate-control.all@tools.ietf.org<mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>; sip-overload@ietf.org<mailto:sip-overload@ietf.org> Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Noel, I forgot to respond to your reply about the IANA registration of "rate" in oc-algo. I see that draft-ietf-soc-overload-control-13 mentions your I-D but does not have "rate" in algo-list. There are two possible ways to address "rate" in algo-list. One is to have draft-ietf-soc-overload-control-13 add "rate" to algo-list and refer to your I-D for details. The other is to register "rate" in algo-list with IANA in your I-D, and this should be a simple task. The cleaner way that is more inline with the IETF process would be the latter. It seems odd to have something defined in a RFC without details about it, and it would be too much trouble to combine the two I-Ds. James From: Yu, James Sent: Wednesday, July 10, 2013 9:01 AM To: 'NOEL, ERIC C (ERIC C)' Cc: sip-overload-bounces@ietf.org<mailto:sip-overload-bounces@ietf.org>; draft-ietf-soc-overload-rate-control.all@tools.ietf.org<mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>; sip-overload@ietf.org<mailto:sip-overload@ietf.org> Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt 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:ecnoel@research.att.com] Sent: Tuesday, July 09, 2013 4:44 PM To: Yu, James; Janet P Gunn Cc: sip-overload-bounces@ietf.org<mailto:sip-overload-bounces@ietf.org>; draft-ietf-soc-overload-rate-control.all@tools.ietf.org<mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>; sip-overload@ietf.org<mailto:sip-overload@ietf.org> 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 ecnoel@att.com<mailto:jsmith@att.com> From: sip-overload-bounces@ietf.org<mailto:sip-overload-bounces@ietf.org> [mailto:sip-overload-bounces@ietf.org] On Behalf Of Yu, James Sent: Tuesday, July 02, 2013 9:42 AM To: Janet P Gunn Cc: sip-overload-bounces@ietf.org<mailto:sip-overload-bounces@ietf.org>; draft-ietf-soc-overload-rate-control.all@tools.ietf.org<mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>; sip-overload@ietf.org<mailto:sip-overload@ietf.org> 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:jgunn6@csc.com] Sent: Friday, June 28, 2013 3:34 PM To: Yu, James Cc: draft-ietf-soc-overload-rate-control.all@tools.ietf.org<mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>; sip-overload@ietf.org<mailto:sip-overload@ietf.org>; sip-overload-bounces@ietf.org<mailto:sip-overload-bounces@ietf.org> 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" <james.yu@neustar.biz<mailto:james.yu@neustar.biz>> To: "sip-overload-bounces@ietf.org<mailto:sip-overload-bounces@ietf.org>" <sip-overload-bounces@ietf.org<mailto:sip-overload-bounces@ietf.org>>, "draft-ietf-soc-overload-rate-control.all@tools.ietf.org<mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>" <draft-ietf-soc-overload-rate-control.all@tools.ietf.org<mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>>, "sip-overload@ietf.org<mailto:sip-overload@ietf.org>" <sip-overload@ietf.org<mailto:sip-overload@ietf.org>> Date: 06/28/2013 08:10 AM Subject: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt Sent by: sip-overload-bounces@ietf.org<mailto:sip-overload-bounces@ietf.org> ________________________________ 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 sip-overload@ietf.org<mailto:sip-overload@ietf.org> https://www.ietf.org/mailman/listinfo/sip-overload ________________________________ No virus found in this message. Checked by AVG - www.avg.com<http://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<http://www.avg.com> Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com<http://www.avg.com> Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13 ________________________________ No virus found in this message. Checked by AVG - www.avg.com<http://www.avg.com> Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13
- [sip-overload] draft-ietf-soc-overload-rate-contr… Yu, James
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… Janet P Gunn
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… Yu, James
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… NOEL, ERIC C (ERIC C)
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… Yu, James
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… Janet P Gunn
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… Yu, James
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… Yu, James
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… NOEL, ERIC C (ERIC C)
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… NOEL, ERIC C (ERIC C)
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… Yu, James
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… NOEL, ERIC C (ERIC C)
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… Yu, James
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… NOEL, ERIC C (ERIC C)
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… DRAGE, Keith (Keith)
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… DRAGE, Keith (Keith)
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… NOEL, ERIC C (ERIC C)
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… Christer Holmberg
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… Christer Holmberg
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… NOEL, ERIC C (ERIC C)
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… NOEL, ERIC C (ERIC C)
- Re: [sip-overload] draft-ietf-soc-overload-rate-c… Christer Holmberg
- [sip-overload] draft-ietf-soc-overload-control-13 Yu, James
- Re: [sip-overload] draft-ietf-soc-overload-contro… Vijay K. Gurbani
- Re: [sip-overload] draft-ietf-soc-overload-contro… Janet P Gunn
- Re: [sip-overload] draft-ietf-soc-overload-contro… Yu, James
- Re: [sip-overload] draft-ietf-soc-overload-contro… Christer Holmberg
- Re: [sip-overload] draft-ietf-soc-overload-contro… Yu, James
- Re: [sip-overload] draft-ietf-soc-overload-contro… Christer Holmberg
- Re: [sip-overload] draft-ietf-soc-overload-contro… Yu, James
- Re: [sip-overload] draft-ietf-soc-overload-contro… Vijay K. Gurbani
- Re: [sip-overload] draft-ietf-soc-overload-contro… Christer Holmberg