From jgunn6@csc.com Mon Mar 4 12:59:43 2013 Return-Path: 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 70C2621F8EF6; Mon, 4 Mar 2013 12:59:43 -0800 (PST) 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=[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 AyGkEZ-InnmU; Mon, 4 Mar 2013 12:59:42 -0800 (PST) Received: from mail170.messagelabs.com (mail170.messagelabs.com [216.82.253.227]) by ietfa.amsl.com (Postfix) with ESMTP id 2837621F8F07; Mon, 4 Mar 2013 12:59:36 -0800 (PST) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-9.tower-170.messagelabs.com!1362430773!20452551!1 X-Originating-IP: [20.137.2.88] X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25535 invoked from network); 4 Mar 2013 20:59:34 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-9.tower-170.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Mar 2013 20:59:34 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r24KxWnT018606; Mon, 4 Mar 2013 15:59:33 -0500 In-Reply-To: <51189F14.6050405@ericsson.com> References: <51110A56.7030402@ericsson.com> <51189F14.6050405@ericsson.com> To: Salvatore Loreto MIME-Version: 1.0 X-KeepSent: 9C231A23:1CBBAECC-85257B24:0070CB1D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Mon, 4 Mar 2013 15:59:31 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 03/04/2013 03:54:13 PM, Serialize complete at 03/04/2013 03:54:13 PM Content-Type: multipart/alternative; boundary="=_alternative 00734FC485257B24_=" Cc: sip-overload-bounces@ietf.org, Volker Hilt , "sip-overload@ietf.org" Subject: [sip-overload] Sec 5.8 Re: WG Last Call for draft-ietf-soc-overload-control-12 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 20:59:43 -0000 This is a multipart message in MIME format. --=_alternative 00734FC485257B24_= Content-Type: text/plain; charset="US-ASCII" I am having some problems with the basic premise of sec 5.8, Stabilizing overload algorithm selection. I completely agree with the intent: " Once the client and server agree on an overload control algorithm, it MUST remain in effect for at least 3600 seconds (1 hour) before another change occurs." but I am having some problems with the mechanism. The basic mechanism for selecting the algorithm is that the client includes a list of "algorithms supported" in the request sent to the server. In return, the server includes the single algorithm that the server has selected from the list. There is no opportunity for the client to either "agree" or "disagree" with the server. Therefore, the onus of " MUST remain in effect for at least 3600 seconds (1 hour) before another change occurs." lies entirely with the server, not the client. The existing text "the client should save the time of the last algorithm change with a server and only agree to change it again after a time period of at least 3600 seconds." is not possible to implement as the client has no way to tell the server "no, I am not changing algorithms yet". As far as I can see, if the server misbehaves by sending a new algorithm too soon, the client only has two options A - Go along with the new algorithm identified by the server , even if it has been less than 3600 seconds B- Drop out of the overload control process all together- stop sending ANY oc parameters. I think that, in most cases, A is preferable to B. I suggest the following rewording. " Realities of deployments of SIP necessitate that the overload control algorithm may be changed upon a system reboot or a software upgrade. However, frequent changes of the overload control algorithm MUST be avoided. Frequent changes of the overload control algorithm will not benefit the client or the server as such flapping does not allow the chosen algorithm to stabilize. An algorithm change, when desired, is simply accomplished by the SIP server choosing a new algorithm from the list in the client's "oc-algo" parameter and sending it back to the client in a response. The client associates a specific algorithm with each server it sends traffic to and when the server changes the algorithm, the client must change its behaviour accordingly. Once the server selects a specific overload control algorithm for a given client, it MUST remain in effect for at least 3600 seconds (1 hour) before another change occurs. This period may involve one or more cycles of overload control being in effect and then being stopped depending on the traffic and resources at the server. One way to accomplish this involves the server saving the time of the last algorithm change in a lookup table, indexed by the client's network identifiers. The server only changes oc-algo when the time since the last change has surpassed 3600 seconds." Janet From: Salvatore Loreto To: "sip-overload@ietf.org" Cc: Volker Hilt Date: 02/11/2013 02:35 AM Subject: Re: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12 Sent by: sip-overload-bounces@ietf.org this is just a reminder for this WG Last Call I haven't seen yet any comment or feedback please we really need you spend some time to reading and reviewing the draft thanks a lot Salvatore On 2/5/13 3:34 PM, Salvatore Loreto wrote: Dear WG partecipants, Volker and I would like to initiate a second 2 weeks WG Last Call on draft-ietf-soc-overload-control-12 (" Session Initiation Protocol (SIP) Overload Control") http://tools.ietf.org/id/draft-ietf-soc-overload-control-12.txt The first WGLC that we run ( http://www.ietf.org/mail-archive/web/sip-overload/current/msg00731.html ) has produced a significant amount of feedback and comments that have been discussed and addressed in subsequent versions Please send your reviews, as well as expression of support regarding document readiness for IESG (or not) either to the *soc* mailing list ( sip-overload@ietf.org), or directly to the WG chairs (Murray Kucherawy and myself). Comments like "I've read the document and it is Ok to publish" or "I've read the document and it has the following issues" are useful and would be gratefully accepted by chairs. The WG LC will end on Friday, February 19th. Thank you, Salvatore as an SoC co-chair. _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload --=_alternative 00734FC485257B24_= Content-Type: text/html; charset="US-ASCII" I am having some problems with the basic premise of sec 5.8, Stabilizing overload algorithm selection.

I completely agree with the intent:
 "  Once the client and server agree on an overload control algorithm, it    MUST remain in effect for at least 3600 seconds (1 hour) before  another change occurs."
but I am having some problems with the mechanism.

The basic mechanism for selecting the algorithm is that the client includes a list of "algorithms supported" in the request sent to the server.
In return, the server includes the single algorithm that the server has selected from the list.

There is no opportunity for the client to either "agree" or "disagree" with the server.

Therefore, the onus of  "  MUST remain in effect for at least 3600 seconds (1 hour) before another change occurs." lies entirely with the server, not the client.

The existing text "the client should save the time of the last algorithm change with a server and only agree to change it again after a time period of at least 3600 seconds." is not possible to implement as the client has no way to tell the server "no, I am not changing algorithms yet".  

As far as I can see, if the server misbehaves by sending a new algorithm too soon, the client only has two options
A - Go along with the new algorithm identified by the server , even if it has been less than 3600 seconds
B- Drop out of the overload control process all together- stop sending ANY oc parameters.

I think that, in most cases, A is preferable to B.

I suggest the following rewording.

"   Realities of deployments of SIP necessitate that the overload control
   algorithm may be changed upon a system reboot or a software upgrade.
   However, frequent changes of the overload control algorithm MUST be
   avoided.  Frequent changes of the overload control algorithm will not
   benefit the client or the server as such flapping does not allow the
   chosen algorithm to stabilize.  An algorithm change, when desired, is
   simply accomplished by the SIP server choosing a new algorithm from
   the list in the client's "oc-algo" parameter and sending it back to
   the client in a response.

   The client associates a specific algorithm with each server it sends
   traffic to and when the server changes the algorithm, the client must
   change its behaviour accordingly.

   Once the server selects a specific overload control algorithm for a given client, it
   MUST remain in effect for at least 3600 seconds (1 hour) before
   another change occurs.  This period may involve one or more cycles of
   overload control being in effect and then being stopped depending on
   the traffic and resources at the server.

      One way to accomplish this involves the server saving the time of
      the last algorithm change in a lookup table, indexed by the
      client's network identifiers.  The server only changes oc-algo
      when the time since the last change has surpassed 3600 seconds."
Janet


From:        Salvatore Loreto <salvatore.loreto@ericsson.com>
To:        "sip-overload@ietf.org" <sip-overload@ietf.org>
Cc:        Volker Hilt <volker.hilt@alcatel-lucent.com>
Date:        02/11/2013 02:35 AM
Subject:        Re: [sip-overload] WG Last Call for        draft-ietf-soc-overload-control-12
Sent by:        sip-overload-bounces@ietf.org



this is just a reminder for this WG Last Call

I haven't seen yet any comment or feedback
please we really need you spend some time to reading and reviewing the draft

thanks a lot
Salvatore

On 2/5/13 3:34 PM, Salvatore Loreto wrote:
Dear WG partecipants,


Volker and I would like to initiate a second 2 weeks WG Last Call on
draft-ietf-soc-overload-control-12 (" Session Initiation Protocol (SIP) Overload Control")
http://tools.ietf.org/id/draft-ietf-soc-overload-control-12.txt

The first WGLC that we run ( http://www.ietf.org/mail-archive/web/sip-overload/current/msg00731.html )
has produced a significant amount of feedback and comments that have been discussed and addressed in subsequent versions

Please send your reviews, as well as expression of support regarding
document readiness for IESG (or not) either to the *soc* mailing list (sip-overload@ietf.org),
or directly to the WG chairs (Murray Kucherawy and myself).

Comments like "I've read the document and it is Ok to publish" or
"I've read the document and it has the following issues"
are useful and would be gratefully accepted by chairs.


The WG LC will end on Friday, February 19th.


Thank you,
Salvatore as an SoC co-chair.


_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload
--=_alternative 00734FC485257B24_=-- From jgunn6@csc.com Wed Mar 6 18:07:38 2013 Return-Path: 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 71B7121F871C; Wed, 6 Mar 2013 18:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, 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 ZG7Oa9kQQTW6; Wed, 6 Mar 2013 18:07:37 -0800 (PST) Received: from mail86.messagelabs.com (mail86.messagelabs.com [216.82.242.179]) by ietfa.amsl.com (Postfix) with ESMTP id B06E221F8732; Wed, 6 Mar 2013 18:07:30 -0800 (PST) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-11.tower-86.messagelabs.com!1362622048!38477878!1 X-Originating-IP: [20.137.52.151] X-StarScan-Received: X-StarScan-Version: 6.8.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22048 invoked from network); 7 Mar 2013 02:07:29 -0000 Received: from amer-mta07.csc.com (HELO amer-mta07.csc.com) (20.137.52.151) by server-11.tower-86.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Mar 2013 02:07:29 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id r2727RsC016135; Wed, 6 Mar 2013 21:07:28 -0500 (EST) In-Reply-To: <51189F14.6050405@ericsson.com> References: <51110A56.7030402@ericsson.com> <51189F14.6050405@ericsson.com> To: Salvatore Loreto MIME-Version: 1.0 X-KeepSent: 1EFD032C:5418DF57-85257B27:000B56FE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Wed, 6 Mar 2013 21:06:54 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 03/06/2013 09:02:07 PM, Serialize complete at 03/06/2013 09:02:07 PM Content-Type: multipart/alternative; boundary="=_alternative 000B8FC985257B27_=" Cc: sip-overload-bounces@ietf.org, Volker Hilt , "sip-overload@ietf.org" Subject: [sip-overload] Sec 5 and 6 Re: WG Last Call for draft-ietf-soc-overload-control-12 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 02:07:38 -0000 This is a multipart message in MIME format. --=_alternative 000B8FC985257B27_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 U2VjIDUuMTAuMiBSZWplY3RpbmcgUmVxdWVzdHMgYXQgYW4gb3ZlcmxvYWRlZCBzZXJ2ZXIuDQoN CkkgYWdyZWUgd2l0aCB0aGUgY29uY2VwdA0K4oCcSXQgd291bGQgYmUgZmFpciB0byBkZXZvdGUg dGhlIHNhbWUgYW1vdW50DQogICBvZiBwcm9jZXNzaW5nIGF0IHRoZSBvdmVybG9hZGVkIHNlcnZl ciB0byB0aGUgY29tYmluYXRpb24gb2YNCiAgIHJlamVjdGlvbiBhbmQgcHJvY2Vzc2luZyBmcm9t IGEgbm9uLXBhcnRpY2lwYXRpbmcgY2xpZW50IGFzIHRoZQ0KICAgb3ZlcmxvYWRlZCBzZXJ2ZXIg d291bGQgZGV2b3RlIHRvIHByb2Nlc3NpbmcgcmVxdWVzdHMgZnJvbSBhDQogICBwYXJ0aWNpcGF0 aW5nIGNsaWVudC7igJ0NCg0KQnV0IGhvdyBpcyB0aGUgc2VydmVyIHRvIGtub3cgaG93IG11Y2gg aXQg4oCcd291bGQgZGV2b3RlIHRvIHByb2Nlc3NpbmcgDQpyZXF1ZXN0cyBmcm9tIGEgIHBhcnRp Y2lwYXRpbmcgY2xpZW50LuKAnSBFc3BlY2lhbGx5IHVuZGVyIHRoZSBsb3NzIHNjaGVtZS4NCg0K SXQgc2VlbXMgdG8gbWUgdGhhdCBpdCB3b3VsZCBtYWtlIG1vcmUgc2Vuc2UgdG8gZXN0aW1hdGUN ClIgPSByYXRpbyBvZiAocHJvY2Vzc2luZyByZXF1aXJlZCB0byByZWplY3QgYSByZXF1ZXN0KSB0 byAocHJvY2Vzc2luZyANCnJlcXVpcmVkIHRvIHByb2Nlc3MgYSByZXF1ZXN0KQ0KDQpUaGVuIGZv ciB0aGUgbG9zcyBhbGdvcml0aG0sIGlmIHRoZSBzZXJ2ZXIgd291bGQgaGF2ZSBzZXQgb2M9eCwg aXQgc2hvdWxkIA0KcmVqZWN0ICgxK1IpeCAlIG9mIHRoZSByZXF1ZXN0cyBmcm9tIHRoZSBub24g cGFydGljaXBhdGluZyBjbGllbnQuDQoNCkZvciB0aGUgcmF0ZSBhbGdvcml0aG0sICAgaWYgdGhl IHNlcnZlciB3b3VsZCBoYXZlIHNldCBvYz14LCBpdCBzaG91bGQgDQpyZWplY3QgYW55dGhpbmcg b3ZlciB4LyAoMStSKSByZXF1ZXN0cyBwZXIgc2Vjb25kIGZyb20gdGhlIG5vbiANCnBhcnRpY2lw YXRpbmcgY2xpZW50Lg0KDQoNClNlYyA2LjINCuKAnHNvbWUgYWxnb3JpdGhtIGNhbGxlZCAiQSIu 4oCdDQoNCklzIHRoZXJlIGFueSB3YXkgdG8gYmUgc3VyZSB0aGF0LCB3aGVuIHRoZSBjbGllbnQg c2F5cyDigJxB4oCdIGFuZCB0aGUgc2VydmVyIA0Kc2F5cyDigJxB4oCdLCB0aGV5IG1lYW4gdGhl IHNhbWUgdGhpbmc/DQoNCg0KSmFuZXQNCg0KVGhpcyBpcyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIA0KZGVsZXRlIHdpdGhv dXQgY29weWluZyBhbmQga2luZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YgdGhlIG1pc3Rha2Ug aW4gDQpkZWxpdmVyeS4gTk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0aGlzIGUtbWFpbCBz aGFsbCBub3Qgb3BlcmF0ZSB0byANCmJpbmQgQ1NDIHRvIGFueSBvcmRlciBvciBvdGhlciBjb250 cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgDQp3cml0dGVuIGFncmVlbWVudCBvciBn b3Zlcm5tZW50IGluaXRpYXRpdmUgZXhwcmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiANCmUt bWFpbCBmb3Igc3VjaCBwdXJwb3NlLg0KDQoNCg0KRnJvbTogICBTYWx2YXRvcmUgTG9yZXRvIDxz YWx2YXRvcmUubG9yZXRvQGVyaWNzc29uLmNvbT4NClRvOiAgICAgInNpcC1vdmVybG9hZEBpZXRm Lm9yZyIgPHNpcC1vdmVybG9hZEBpZXRmLm9yZz4NCkNjOiAgICAgVm9sa2VyIEhpbHQgPHZvbGtl ci5oaWx0QGFsY2F0ZWwtbHVjZW50LmNvbT4NCkRhdGU6ICAgMDIvMTEvMjAxMyAwMjozNSBBTQ0K U3ViamVjdDogICAgICAgIFJlOiBbc2lwLW92ZXJsb2FkXSBXRyBMYXN0IENhbGwgZm9yIA0KZHJh ZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbC0xMg0KU2VudCBieTogICAgICAgIHNpcC1vdmVy bG9hZC1ib3VuY2VzQGlldGYub3JnDQoNCg0KDQp0aGlzIGlzIGp1c3QgYSByZW1pbmRlciBmb3Ig dGhpcyBXRyBMYXN0IENhbGwNCg0KSSBoYXZlbid0IHNlZW4geWV0IGFueSBjb21tZW50IG9yIGZl ZWRiYWNrIA0KcGxlYXNlIHdlIHJlYWxseSBuZWVkIHlvdSBzcGVuZCBzb21lIHRpbWUgdG8gcmVh ZGluZyBhbmQgcmV2aWV3aW5nIHRoZSANCmRyYWZ0DQoNCnRoYW5rcyBhIGxvdA0KU2FsdmF0b3Jl DQoNCk9uIDIvNS8xMyAzOjM0IFBNLCBTYWx2YXRvcmUgTG9yZXRvIHdyb3RlOg0KRGVhciBXRyBw YXJ0ZWNpcGFudHMsIA0KDQoNClZvbGtlciBhbmQgSSB3b3VsZCBsaWtlIHRvIGluaXRpYXRlIGEg c2Vjb25kIDIgd2Vla3MgV0cgTGFzdCBDYWxsIG9uIA0KZHJhZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQt Y29udHJvbC0xMiAoIiBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkgDQpPdmVybG9h ZCBDb250cm9sIikgDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1zb2Mtb3Zl cmxvYWQtY29udHJvbC0xMi50eHQNCg0KVGhlIGZpcnN0IFdHTEMgdGhhdCB3ZSBydW4gKCANCmh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXAtb3ZlcmxvYWQvY3VycmVudC9t c2cwMDczMS5odG1sICkNCmhhcyBwcm9kdWNlZCBhIHNpZ25pZmljYW50IGFtb3VudCBvZiBmZWVk YmFjayBhbmQgY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gDQpkaXNjdXNzZWQgYW5kIGFkZHJlc3Nl ZCBpbiBzdWJzZXF1ZW50IHZlcnNpb25zDQoNClBsZWFzZSBzZW5kIHlvdXIgcmV2aWV3cywgYXMg d2VsbCBhcyBleHByZXNzaW9uIG9mIHN1cHBvcnQgcmVnYXJkaW5nIA0KZG9jdW1lbnQgcmVhZGlu ZXNzIGZvciBJRVNHIChvciBub3QpIGVpdGhlciB0byB0aGUgKnNvYyogbWFpbGluZyBsaXN0ICgN CnNpcC1vdmVybG9hZEBpZXRmLm9yZyksIA0Kb3IgZGlyZWN0bHkgdG8gdGhlIFdHIGNoYWlycyAo TXVycmF5IEt1Y2hlcmF3eSBhbmQgbXlzZWxmKS4gDQoNCkNvbW1lbnRzIGxpa2UgIkkndmUgcmVh ZCB0aGUgZG9jdW1lbnQgYW5kIGl0IGlzIE9rIHRvIHB1Ymxpc2giIG9yIA0KIkkndmUgcmVhZCB0 aGUgZG9jdW1lbnQgYW5kIGl0IGhhcyB0aGUgZm9sbG93aW5nIGlzc3VlcyINCmFyZSB1c2VmdWwg YW5kIHdvdWxkIGJlIGdyYXRlZnVsbHkgYWNjZXB0ZWQgYnkgY2hhaXJzLiANCg0KDQpUaGUgV0cg TEMgd2lsbCBlbmQgb24gRnJpZGF5LCBGZWJydWFyeSAxOXRoLiANCg0KDQpUaGFuayB5b3UsIA0K U2FsdmF0b3JlIGFzIGFuIFNvQyBjby1jaGFpci4gDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcC1vdmVybG9hZCBtYWlsaW5nIGxpc3QNCnNp cC1vdmVybG9hZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaXAtb3ZlcmxvYWQNCg0KDQo= --=_alternative 000B8FC985257B27_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlNlYyA1LjEwLjIgUmVqZWN0aW5nIFJlcXVlc3Rz IGF0IGFuIG92ZXJsb2FkZWQNCnNlcnZlci48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkNhbGlicmkiPkkgYWdyZWUgd2l0aCB0aGUgY29uY2VwdDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+4oCcSXQgd291bGQgYmUgZmFpciB0byBkZXZvdGUgdGhl IHNhbWUgYW1vdW50PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJz cDsgJm5ic3A7b2YgcHJvY2Vzc2luZyBhdCB0aGUgb3ZlcmxvYWRlZA0Kc2VydmVyIHRvIHRoZSBj b21iaW5hdGlvbiBvZjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5i c3A7ICZuYnNwO3JlamVjdGlvbiBhbmQgcHJvY2Vzc2luZyBmcm9tDQphIG5vbi1wYXJ0aWNpcGF0 aW5nIGNsaWVudCBhcyB0aGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmki PiZuYnNwOyAmbmJzcDtvdmVybG9hZGVkIHNlcnZlciB3b3VsZCBkZXZvdGUNCnRvIHByb2Nlc3Np bmcgcmVxdWVzdHMgZnJvbSBhPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJp Ij4mbmJzcDsgJm5ic3A7cGFydGljaXBhdGluZyBjbGllbnQu4oCdPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5CdXQgaG93IGlzIHRoZSBzZXJ2ZXIgdG8ga25v dyBob3cgbXVjaA0KaXQg4oCcd291bGQgZGV2b3RlIHRvIHByb2Nlc3NpbmcgcmVxdWVzdHMgZnJv bSBhICZuYnNwO3BhcnRpY2lwYXRpbmcgY2xpZW50LuKAnQ0KRXNwZWNpYWxseSB1bmRlciB0aGUg bG9zcyBzY2hlbWUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJp Ij5JdCBzZWVtcyB0byBtZSB0aGF0IGl0IHdvdWxkIG1ha2UgbW9yZQ0Kc2Vuc2UgdG8gZXN0aW1h dGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlIgPSByYXRpbyBvZiAo cHJvY2Vzc2luZyByZXF1aXJlZCB0byByZWplY3QNCmEgcmVxdWVzdCkgdG8gKHByb2Nlc3Npbmcg cmVxdWlyZWQgdG8gcHJvY2VzcyBhIHJlcXVlc3QpPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDYWxpYnJpIj5UaGVuIGZvciB0aGUgbG9zcyBhbGdvcml0aG0sIGlmIHRoZSBz ZXJ2ZXINCndvdWxkIGhhdmUgc2V0IG9jPXgsIGl0IHNob3VsZCByZWplY3QgKDErUil4ICUgb2Yg dGhlIHJlcXVlc3RzIGZyb20gdGhlDQpub24gcGFydGljaXBhdGluZyBjbGllbnQuPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5Gb3IgdGhlIHJhdGUgYWxnb3Jp dGhtLCAmbmJzcDsgaWYgdGhlIHNlcnZlcg0Kd291bGQgaGF2ZSBzZXQgb2M9eCwgaXQgc2hvdWxk IHJlamVjdCBhbnl0aGluZyBvdmVyIHgvICgxK1IpIHJlcXVlc3RzIHBlcg0Kc2Vjb25kIGZyb20g dGhlIG5vbiBwYXJ0aWNpcGF0aW5nIGNsaWVudC48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlNlYyA2LjI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkNhbGlicmkiPuKAnHNvbWUgYWxnb3JpdGhtIGNhbGxlZCAmcXVvdDtBJnF1b3Q7LuKA nTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+SXMgdGhlcmUg YW55IHdheSB0byBiZSBzdXJlIHRoYXQsIHdoZW4NCnRoZSBjbGllbnQgc2F5cyDigJxB4oCdIGFu ZCB0aGUgc2VydmVyIHNheXMg4oCcQeKAnSwgdGhleSBtZWFuIHRoZSBzYW1lIHRoaW5nPzwvZm9u dD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SmFuZXQ8 YnI+DQo8YnI+DQpUaGlzIGlzIGEgUFJJVkFURSBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UNCmRlbGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5kIGtp bmRseSBhZHZpc2UgdXMgYnkgZS1tYWlsIG9mIHRoZSBtaXN0YWtlIGluDQpkZWxpdmVyeS4gTk9U RTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0aGlzIGUtbWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0 bw0KYmluZCBDU0MgdG8gYW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFu dCB0byBleHBsaWNpdCB3cml0dGVuDQphZ3JlZW1lbnQgb3IgZ292ZXJubWVudCBpbml0aWF0aXZl IGV4cHJlc3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2YgZS1tYWlsDQpmb3Igc3VjaCBwdXJwb3Nl LjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1 ZiBmYWNlPSJzYW5zLXNlcmlmIj5Gcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9m b250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TYWx2YXRvcmUgTG9yZXRvICZsdDtz YWx2YXRvcmUubG9yZXRvQGVyaWNzc29uLmNvbSZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0x IGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+VG86ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O3NpcC1v dmVybG9hZEBpZXRmLm9yZyZxdW90Ow0KJmx0O3NpcC1vdmVybG9hZEBpZXRmLm9yZyZndDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+Q2M6 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPlZvbGtlciBIaWx0ICZsdDt2b2xrZXIuaGlsdEBhbGNhdGVsLWx1Y2VudC5jb20m Z3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2Vy aWYiPkRhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPjAyLzExLzIwMTMgMDI6MzUgQU08L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+U3ViamVjdDogJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ UmU6IFtzaXAtb3ZlcmxvYWRdDQpXRyBMYXN0IENhbGwgZm9yICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2RyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNvbnRyb2wtMTI8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+U2VudCBieTogJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8YnI+DQo8aHIgbm9zaGFk ZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+dGhpcyBpcyBqdXN0IGEgcmVtaW5kZXIg Zm9yIHRoaXMgV0cgTGFzdCBDYWxsPGJyPg0KPGJyPg0KSSBoYXZlbid0IHNlZW4geWV0IGFueSBj b21tZW50IG9yIGZlZWRiYWNrIDxicj4NCnBsZWFzZSB3ZSByZWFsbHkgbmVlZCB5b3Ugc3BlbmQg c29tZSB0aW1lIHRvIHJlYWRpbmcgYW5kIHJldmlld2luZyB0aGUNCmRyYWZ0PGJyPg0KPGJyPg0K dGhhbmtzIGEgbG90PGJyPg0KU2FsdmF0b3JlPGJyPg0KPGJyPg0KT24gMi81LzEzIDM6MzQgUE0s IFNhbHZhdG9yZSBMb3JldG8gd3JvdGU6PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5EZWFyIFdH IHBhcnRlY2lwYW50cywgPGJyPg0KPGJyPg0KPGJyPg0KVm9sa2VyIGFuZCBJIHdvdWxkIGxpa2Ug dG8gaW5pdGlhdGUgYSBzZWNvbmQgMiB3ZWVrcyBXRyBMYXN0IENhbGwgb24gPGJyPg0KZHJhZnQt aWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbC0xMiAoJnF1b3Q7IFNlc3Npb24gSW5pdGlhdGlvbiBQ cm90b2NvbA0KKFNJUCkgT3ZlcmxvYWQgQ29udHJvbCZxdW90OykgPC9mb250Pjxmb250IHNpemU9 MyBjb2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnL2lkL2RyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNvbnRyb2wtMTIudHh0Ij48Zm9udCBz aXplPTMgY29sb3I9Ymx1ZT48dT5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1z b2Mtb3ZlcmxvYWQtY29udHJvbC0xMi50eHQ8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+PGJy Pg0KPGJyPg0KVGhlIGZpcnN0IFdHTEMgdGhhdCB3ZSBydW4gKCA8L2ZvbnQ+PGEgaHJlZj0iaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcC1vdmVybG9hZC9jdXJyZW50L21z ZzAwNzMxLmh0bWwiPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pmh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9zaXAtb3ZlcmxvYWQvY3VycmVudC9tc2cwMDczMS5odG1sPC91 PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPg0KKTxicj4NCmhhcyBwcm9kdWNlZCBhIHNpZ25pZmlj YW50IGFtb3VudCBvZiBmZWVkYmFjayBhbmQgY29tbWVudHMgdGhhdCBoYXZlIGJlZW4NCmRpc2N1 c3NlZCBhbmQgYWRkcmVzc2VkIGluIHN1YnNlcXVlbnQgdmVyc2lvbnM8YnI+DQo8YnI+DQpQbGVh c2Ugc2VuZCB5b3VyIHJldmlld3MsIGFzIHdlbGwgYXMgZXhwcmVzc2lvbiBvZiBzdXBwb3J0IHJl Z2FyZGluZyA8YnI+DQpkb2N1bWVudCByZWFkaW5lc3MgZm9yIElFU0cgKG9yIG5vdCkgZWl0aGVy IHRvIHRoZSA8Yj4qc29jKjwvYj4gbWFpbGluZw0KbGlzdCAoPC9mb250PjxhIGhyZWY9Im1haWx0 bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmciPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1PnNpcC1v dmVybG9hZEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4pLA0KPGJyPg0Kb3Ig ZGlyZWN0bHkgdG8gdGhlIFdHIGNoYWlycyAoTXVycmF5IEt1Y2hlcmF3eSBhbmQgbXlzZWxmKS4g PGJyPg0KPGJyPg0KQ29tbWVudHMgbGlrZSAmcXVvdDtJJ3ZlIHJlYWQgdGhlIGRvY3VtZW50IGFu ZCBpdCBpcyBPayB0byBwdWJsaXNoJnF1b3Q7DQpvciA8YnI+DQomcXVvdDtJJ3ZlIHJlYWQgdGhl IGRvY3VtZW50IGFuZCBpdCBoYXMgdGhlIGZvbGxvd2luZyBpc3N1ZXMmcXVvdDs8YnI+DQphcmUg dXNlZnVsIGFuZCB3b3VsZCBiZSBncmF0ZWZ1bGx5IGFjY2VwdGVkIGJ5IGNoYWlycy4gPGJyPg0K PGJyPg0KPGJyPg0KVGhlIFdHIExDIHdpbGwgZW5kIG9uIEZyaWRheSwgRmVicnVhcnkgMTl0aC4g PGJyPg0KPGJyPg0KPGJyPg0KVGhhbmsgeW91LCA8YnI+DQpTYWx2YXRvcmUgYXMgYW4gU29DIGNv LWNoYWlyLiA8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9udD48dHQ+ PGZvbnQgc2l6ZT0yPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0Kc2lwLW92ZXJsb2FkIG1haWxpbmcgbGlzdDxicj4NCnNpcC1vdmVybG9hZEBpZXRm Lm9yZzxicj4NCjwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2lwLW92ZXJsb2FkIj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwLW92ZXJsb2FkPC9mb250PjwvdHQ+PC9hPjx0dD48 Zm9udCBzaXplPTI+PGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo= --=_alternative 000B8FC985257B27_=-- From yang.hong@inbaytech.com Thu Mar 14 15:02:53 2013 Return-Path: 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 D3A601F0D1A for ; Thu, 14 Mar 2013 15:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 vmy8zwcS8LWE for ; Thu, 14 Mar 2013 15:02:52 -0700 (PDT) Received: from p3plwbeout04-01.prod.phx3.secureserver.net (p3plsmtp04-01-2.prod.phx3.secureserver.net [72.167.218.222]) by ietfa.amsl.com (Postfix) with ESMTP id 58B111F0D16 for ; Thu, 14 Mar 2013 15:02:52 -0700 (PDT) Received: from localhost ([72.167.218.244]) by p3plwbeout04-01.prod.phx3.secureserver.net with bizsmtp id Ba2q1l0035GyNsw01a2q1V; Thu, 14 Mar 2013 15:02:51 -0700 X-SID: Ba2q1l0035GyNsw01 Received: (qmail 6496 invoked by uid 99); 14 Mar 2013 22:02:50 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 134.117.61.236 User-Agent: Workspace Webmail 5.6.34 Message-Id: <20130314150249.9b81bd31c6f0ac9074ffa0f6cc962602.48bfda6d97.wbe@email04.secureserver.net> From: To: sip-overload@ietf.org Date: Thu, 14 Mar 2013 15:02:49 -0700 Mime-Version: 1.0 Subject: [sip-overload] Survey on SIP Overload Control Re: Proposal: Support for the restriction algorithms should be mandatory for clients X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 22:08:10 -0000 =0A=0A
 
=0A<= div>I agree with Eric's comment "As offered load increases, rate control is= the only algorithm that controls load close to the target."=0A
&= nbsp;
=0A
We have also used control theorectic approaches to model= the interactions between an overloaded SIP server and its upstream servers= in two different scenarios (IEEE Globecom 2010 and ICC 2011).
=0A=
"Mitigating SIP Overload Using a Control-Theoretic Approach" IEEE Glob= ecom 2010
http://www.resea= rchgate.net/publication/221284946_Mitigating_SIP_Overload_Using_a_Control-T= heoretic_Approach
=0A
 
=0A
Implementation of im= plicit SIP overload control in the real system
http://link.springer.com= /chapter/10.1007%2F978-3-642-23641-9_15#
=0A
 
=0A"Design Of A PI Rate Controller for Mitigating SIP Overload" IEEE ICC 20= 11
http://www.researchgate= .net/publication/224249824_Design_of_a_PI_Rate_Controller_for_Mitigating_SI= P_Overload
http://features.rr.com/article/01vBgtc8TR17z?q=3DSkype= =0A
 
=0A
Best regards,
=0A
 
=0A
= Winston Hong
Software Engineer
InBay Technologies Inc.
Ottawa, Can= ada K2K 1Y3
http://www.inbaytech.c= om/
=0A
 
=0A
=0A=0A=0A
=0A
Volker, =
=0A=0AWrt Phil's comment on vulnerability to sudden increases on the offere=
d load at client sources, I believe the paper from Arthur Berger in IEEE Tr=
ansactions on Automatic Control Vol 36, No2, February 1991 titled "Overload=
 Control Using Rate Control: Selecting Token Bank Capacity for Robustness t=
o Arrival Rates" supports that observation.=0A=0AIn that paper, Figure 3 co=
mpares rate control to call gapping and to percent blocking. As offered loa=
d increases, rate control is the only algorithm that controls load close to=
 the target. Basically Phil's point.=0A=0ABecause it is a copyrighted docum=
ent, I do not think I can broadcast on distribution list. However, if you c=
annot get a copy of the paper let me know and I will assist you.=0A=0AThank=
s,=0A=0AEric Noel =0ALMTS=0AAT&T Labs, Inc. =0ARethink Possible=0A=0ANe=
twork Design and Performance Analysis=0A200 South Laurel Avenue, D5-3D19=0A=
Middletown, NJ 07748=0AP: 732.420.4174=0Aecnoel at att.com
 From internet-drafts@ietf.org Thu Mar 14 21:20:38 2013 Return-Path: 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 BD42A21F8E0C; Thu, 14 Mar 2013 21:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.384 X-Spam-Level: X-Spam-Status: No, score=-102.384 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 VDZN6K37cVBq; Thu, 14 Mar 2013 21:20:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2F421F8DB7; Thu, 14 Mar 2013 21:20:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130315042038.887.31066.idtracker@ietfa.amsl.com> Date: Thu, 14 Mar 2013 21:20:38 -0700 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-load-control-event-package-08.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 04:20:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Overload Control Working Group of the= IETF. Title : A Session Initiation Protocol (SIP) Load Control Event P= ackage Author(s) : Charles Shen Henning Schulzrinne Arata Koike Filename : draft-ietf-soc-load-control-event-package-08.txt Pages : 39 Date : 2013-03-14 Abstract: We define a load control event package for the Session Initiation Protocol (SIP). It allows SIP entities to distribute load filtering policies to other SIP entities in the network. The load filtering policies contain rules to throttle calls based on their source or destination domain, telephone number prefix or for a specific user. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-soc-load-control-event-package There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-load-control-event-packag= e-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From charles.newyork@gmail.com Thu Mar 14 21:30:17 2013 Return-Path: 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 8515A11E80DC for ; Thu, 14 Mar 2013 21:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 3M4xn7V3NQ0E for ; Thu, 14 Mar 2013 21:30:16 -0700 (PDT) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id 82C9811E80A4 for ; Thu, 14 Mar 2013 21:30:12 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id j1so3000563oag.21 for ; Thu, 14 Mar 2013 21:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=ke8YdiVaCKP2yffVH0dq3XnTXW1hhJyE1YXkA7MEh8A=; b=IxBrkgoeMlLsUJhsEd1rq7RaKMwOVYxhBf7A3cQeheF2esIbAb7Tt4di3xEteQLy0y zY8ijvr9hAVYCdKqj5lWFbiGL+X0KCbgvfv6t8bmvtonQXHy95pRqesJViDwBUEHNi+e BHngfDk6+OUs67MkJc6xd+cJWh8hjv7PAYf5sbzmrhFhmfWu17T9V+klIgwjnIiC7r+H k2Kz1WBNABQpQYN69aDtYlWmRupcUSZCyI8iNB+cItDrz61UzHz9UkVNqXEPF9PJe+4q K2RfMr5Zjn+Hvb+6NqtjWEUKVxDJoFAc3qoXdLzYgy/7QguUWPECEdoFSQJb0w0SHrd9 j9fg== X-Received: by 10.60.6.133 with SMTP id b5mr2311951oea.81.1363321812153; Thu, 14 Mar 2013 21:30:12 -0700 (PDT) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.182.126.230 with HTTP; Thu, 14 Mar 2013 21:29:51 -0700 (PDT) In-Reply-To: <20130315042038.887.31066.idtracker@ietfa.amsl.com> References: <20130315042038.887.31066.idtracker@ietfa.amsl.com> From: Charles Shen Date: Fri, 15 Mar 2013 00:29:51 -0400 X-Google-Sender-Auth: -Qgg63y9LGqY79pnDAr7Zy-Y3Jg Message-ID: To: sip-overload@ietf.org Content-Type: multipart/alternative; boundary=e89a8fb2033453fcdd04d7ef1870 Subject: [sip-overload] Fwd: I-D Action: draft-ietf-soc-load-control-event-package-08.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 04:30:17 -0000 --e89a8fb2033453fcdd04d7ef1870 Content-Type: text/plain; charset=UTF-8 Dear all, a new version with a few minor fixes proposed by Volker has been submitted. 1. Removed the following sentence: "However, feedback control is usually ineffective for overload of more general purpose SIP edge proxy servers." 2. fixed two XML typos. Thanks! Charles ---------- Forwarded message ---------- From: Date: Fri, Mar 15, 2013 at 12:20 AM Subject: [sip-overload] I-D Action: draft-ietf-soc-load-control-event-package-08.txt To: i-d-announce@ietf.org Cc: sip-overload@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP Overload Control Working Group of the IETF. Title : A Session Initiation Protocol (SIP) Load Control Event Package Author(s) : Charles Shen Henning Schulzrinne Arata Koike Filename : draft-ietf-soc-load-control-event-package-08.txt Pages : 39 Date : 2013-03-14 Abstract: We define a load control event package for the Session Initiation Protocol (SIP). It allows SIP entities to distribute load filtering policies to other SIP entities in the network. The load filtering policies contain rules to throttle calls based on their source or destination domain, telephone number prefix or for a specific user. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-soc-load-control-event-package There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-soc-load-control-event-package-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload --e89a8fb2033453fcdd04d7ef1870 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all, a new version with a few minor fixes proposed by Volker has been = submitted.

1. Removed the following sentence: "However, feedbac= k control is usually ineffective for overload of more general purpose SIP e= dge proxy servers."

2. fixed two XML typos.

Thanks!

Charles

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>=
Date: Fri, Mar 15, 2013 at 12:20 AM
Subject: [sip-overload] I-D Action: = draft-ietf-soc-load-control-event-package-08.txt
To: i-d-announce@ietf.org
Cc: sip-overload@ietf.= org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the SIP Overload Control Working Group o= f the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : A Se= ssion Initiation Protocol (SIP) Load Control Event Package
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author(s) =C2=A0 =C2=A0 =C2=A0 : Charles Shen =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Henning Schulzrinne
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Arata Koike
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-soc-load-control-event-package-08.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 39 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2013-03-14

Abstract:
=C2=A0 =C2=A0We define a load control event package for the Session Initiat= ion
=C2=A0 =C2=A0Protocol (SIP). =C2=A0It allows SIP entities to distribute loa= d filtering
=C2=A0 =C2=A0policies to other SIP entities in the network. =C2=A0The load = filtering
=C2=A0 =C2=A0policies contain rules to throttle calls based on their source= or
=C2=A0 =C2=A0destination domain, telephone number prefix or for a specific = user.
=C2=A0 =C2=A0The mechanism helps to prevent signaling overload and compleme= nts
=C2=A0 =C2=A0feedback-based SIP overload control efforts.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-s= oc-load-control-event-package

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-soc-load-c= ontrol-event-package-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft= -ietf-soc-load-control-event-package-08


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
sip-overload mailing list
sip-overload@iet= f.org
https://www.ietf.org/mailman/listinfo/sip-overload

--e89a8fb2033453fcdd04d7ef1870-- From vkg@bell-labs.com Fri Mar 22 08:24:29 2013 Return-Path: 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 1A81321F851C for ; Fri, 22 Mar 2013 08:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 W3GiZr3r5Ibd for ; Fri, 22 Mar 2013 08:24:27 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id A835921F8CF7 for ; Fri, 22 Mar 2013 08:24:25 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r2MFO62O001159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Mar 2013 10:24:06 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r2MFO5Nb025249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Mar 2013 10:24:06 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r2MFO4vE021442; Fri, 22 Mar 2013 10:24:04 -0500 (CDT) Message-ID: <514C783E.8000907@bell-labs.com> Date: Fri, 22 Mar 2013 10:26:54 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: bruno.chatras@orange.com References: <51110A56.7030402@ericsson.com> <51189F14.6050405@ericsson.com> <20305_1360573159_5118B2E6_20305_1921_3_88CAD1D4E8773F42858B58CAA28272A0109278@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <20305_1360573159_5118B2E6_20305_1921_3_88CAD1D4E8773F42858B58CAA28272A0109278@PEXCVZYM12.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: Volker Hilt , "sip-overload@ietf.org" Subject: Re: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 15:24:29 -0000 On 02/11/2013 02:59 AM, bruno.chatras@orange.com wrote: > I just have one comment: > > Section 5.10.2 says that the response sent by a SIP server to > non-participants clients in case of overload is a 503 without the > Retry-After header. I did not find any text about the response sent by > participating clients when they have to reject a request. I assume they > should send a 503 without the Retry-After header as well. I would > suggest adding the following sentence at the end of 5.10, after “it will > need to reject these requests”: In such cases, the SIP client shall > reply to the requests with a 503 response without the Retry-After header. Bruno: Sorry for the delay. Catching up with pending email on SOC. I had a look at Section 5.10.2 and Section 5.10 where you propose to add the above sentence. S5.10 talks about a "SIP client" --- I am trying to figure out if we meant a UAC or a proxy. If this is a proxy, then the behaviour of that is already enumerated in S5.10.2 using the same sentence you specify above. If this is a UAC and it supports overload control, then it has already received overload control feedback from the downstream overloaded server. It will act accordingly. If this is a UAC and it does not support overload control, then it will simply wait for a final response from the downstream server. The UAC, since it does not support overload control, will unfortunately keep sending requests downstream. As such, I am not sure if we need to add anything at all. But I am open to suggestions. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From vkg@bell-labs.com Fri Mar 22 08:27:54 2013 Return-Path: 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 A5F0221F86EA for ; Fri, 22 Mar 2013 08:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 xMZyW7SvUWDs for ; Fri, 22 Mar 2013 08:27:53 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4A80021F86CA for ; Fri, 22 Mar 2013 08:27:52 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r2MFRijY005039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Mar 2013 10:27:45 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r2MFRifk026074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Mar 2013 10:27:44 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r2MFRg56001037; Fri, 22 Mar 2013 10:27:42 -0500 (CDT) Message-ID: <514C7918.4020108@bell-labs.com> Date: Fri, 22 Mar 2013 10:30:32 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Janet P Gunn References: <51110A56.7030402@ericsson.com> <51189F14.6050405@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: Volker Hilt , "sip-overload@ietf.org" Subject: Re: [sip-overload] Introduction - "This document defines..." Re: WG Last Call for draft-ietf-soc-overload-control-12 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 15:27:55 -0000 Janet: Sorry for the delay, circling back to close issues on SOC. Your suggestion below sounds reasonable. I will modify the last paragraph of S1 as you indicate. On 02/21/2013 04:20 PM, Janet P Gunn wrote: > OK, finally getting to this. > > In section 1, the last paragraph ("this document defines...") seems to > miss the main point, which is a protocol for COMMUNICATING overload > information. > > Therefore, I would suggest changing > > " This document defines the general behaviour of SIP servers and > clients involved in overload control in Section 5. In addition, > Section 6 specifies a loss-based overload control scheme. SIP > clients and servers conformant to this specification MUST implement > the loss-based overload control scheme. They MAY implement other > overload control schemes as well." > > to > > " This document defines the protocol for communicating overload > information between SIP servers and clients, so that clients can reduce > the volume of traffic sent to overloaded servers, avoiding congestion > collapse, and increasing usefull throughput. Section 4 describes the > Via header parameters used for this communication. The general > behaviour of SIP servers and clients involved in overload control > is described in Section 5. In addition, > Section 6 specifies a loss-based overload control scheme. SIP > clients and servers conformant to this specification MUST implement > the loss-based overload control scheme. They MAY implement other > overload control schemes as well." Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From vkg@bell-labs.com Fri Mar 22 08:53:51 2013 Return-Path: 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 AFB4B21F8CF7 for ; Fri, 22 Mar 2013 08:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 TBnQ-BM5Ii4K for ; Fri, 22 Mar 2013 08:53:51 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1459C21F853A for ; Fri, 22 Mar 2013 08:53:50 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r2MFrkDS026133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Mar 2013 10:53:47 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r2MFrk3c001990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Mar 2013 10:53:46 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r2MFrjBS008386; Fri, 22 Mar 2013 10:53:45 -0500 (CDT) Message-ID: <514C7F33.4040700@bell-labs.com> Date: Fri, 22 Mar 2013 10:56:35 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Janet P Gunn References: <51110A56.7030402@ericsson.com> <51189F14.6050405@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: Volker Hilt , "sip-overload@ietf.org" Subject: Re: [sip-overload] Sec 5.8 Re: WG Last Call for draft-ietf-soc-overload-control-12 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 15:53:51 -0000 On 03/04/2013 02:59 PM, Janet P Gunn wrote: > I am having some problems with the basic premise of sec 5.8, Stabilizing > overload algorithm selection.[...] > I suggest the following rewording. Janet: Changed as suggested. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From vkg@bell-labs.com Fri Mar 22 08:58:43 2013 Return-Path: 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 3235021F8DE1 for ; Fri, 22 Mar 2013 08:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 TauLVDIylcB1 for ; Fri, 22 Mar 2013 08:58:42 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4E34A21F8586 for ; Fri, 22 Mar 2013 08:58:42 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r2MFwb0t004722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Mar 2013 10:58:38 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r2MFwbtt003365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Mar 2013 10:58:37 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r2MFwZoE011489; Fri, 22 Mar 2013 10:58:35 -0500 (CDT) Message-ID: <514C8055.9060607@bell-labs.com> Date: Fri, 22 Mar 2013 11:01:25 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Janet P Gunn References: <51110A56.7030402@ericsson.com> <51189F14.6050405@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: Volker Hilt , "sip-overload@ietf.org" Subject: Re: [sip-overload] Sec 5 and 6 Re: WG Last Call for draft-ietf-soc-overload-control-12 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 15:58:43 -0000 Janet: Please see inline. There are two open questions resulting from Janet's feedback below. Some WG input will be needed to close them. Please see inline. On 03/06/2013 08:06 PM, Janet P Gunn wrote: > Sec 5.10.2 Rejecting Requests at an overloaded server. > > I agree with the concept > “It would be fair to devote the same amount > of processing at the overloaded server to the combination of > rejection and processing from a non-participating client as the > overloaded server would devote to processing requests from a > participating client.” > > But how is the server to know how much it “would devote to processing > requests from a participating client.” Especially under the loss scheme. > > It seems to me that it would make more sense to estimate > R = ratio of (processing required to reject a request) to (processing > required to process a request) > > Then for the loss algorithm, if the server would have set oc=x, it > should reject (1+R)x % of the requests from the non participating client. > > For the rate algorithm, if the server would have set oc=x, it should > reject anything over x/ (1+R) requests per second from the non > participating client. My question to the WG would be whether we want to go into this level of detail or simply leave it to the implementation to know how much it spends in processing requests from clients? > Sec 6.2 > “some algorithm called "A".” > > Is there any way to be sure that, when the client says “A” and the > server says “A”, they mean the same thing? We register the Via header field parameter (S11), but we do not establish a registry for the tokens that go into the "oc-algo" parameter. Another question to the WG: do we need to establish a registry for the tokens that need to go into the "oc-algo" parameter? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From bruno.chatras@orange.com Fri Mar 22 09:41:52 2013 Return-Path: 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 4068E21F8AAC for ; Fri, 22 Mar 2013 09:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 FMkANdmQAr+5 for ; Fri, 22 Mar 2013 09:41:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E61FB21F8A6F for ; Fri, 22 Mar 2013 09:41:50 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 1432E3B4448; Fri, 22 Mar 2013 17:41:50 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id EA5EE23804B; Fri, 22 Mar 2013 17:41:49 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Fri, 22 Mar 2013 17:41:49 +0100 From: To: "Vijay K. Gurbani" Thread-Topic: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12 Thread-Index: AQHOJxFYYazYaOe4IUWVb8HIVABuvZix5oCA Date: Fri, 22 Mar 2013 16:41:48 +0000 Message-ID: <20666_1363970510_514C89CD_20666_96_1_88CAD1D4E8773F42858B58CAA28272A015CA29@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <51110A56.7030402@ericsson.com> <51189F14.6050405@ericsson.com> <20305_1360573159_5118B2E6_20305_1921_3_88CAD1D4E8773F42858B58CAA28272A0109278@PEXCVZYM12.corporate.adroot.infra.ftgroup> <514C783E.8000907@bell-labs.com> In-Reply-To: <514C783E.8000907@bell-labs.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.21.121514 Cc: Volker Hilt , "sip-overload@ietf.org" Subject: Re: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 16:41:52 -0000 Hi Vijay, I realize that the relation between my question and 5.10.2 was a bit confus= ing. I had in mind the following scenario: A SIP Client (Proxy or a B2BUA) receives a request from a UAC and has to fo= rward it to an overloaded downstream server. This Proxy or B2BUA has receiv= ed overloaded control feedback from the overloaded server. Because of that = it has to reject some requests received from the upstream UAC (It could als= o send it to another destination but as mentioned in clause 5.10: "In many = cases, however, it will need to reject these requests").=20 So my question is: Which SIP response to send in this case? I assume & "503= (Service Unavailable)" response without the Retry-After header would be ap= propriate but I did not find it explicitly stated in the document. Regards, Bruno > -----Message d'origine----- > De=A0: Vijay K. Gurbani [mailto:vkg@bell-labs.com] > Envoy=E9=A0: vendredi 22 mars 2013 16:27 > =C0=A0: CHATRAS Bruno OLNC/OLN > Cc=A0: Salvatore Loreto; sip-overload@ietf.org; Volker Hilt > Objet=A0: Re: [sip-overload] WG Last Call for draft-ietf-soc-overload-con= trol-12 >=20 > On 02/11/2013 02:59 AM, bruno.chatras@orange.com wrote: > > I just have one comment: > > > > Section 5.10.2 says that the response sent by a SIP server to > > non-participants clients in case of overload is a 503 without the > > Retry-After header. I did not find any text about the response sent by > > participating clients when they have to reject a request. I assume > > they should send a 503 without the Retry-After header as well. I would > > suggest adding the following sentence at the end of 5.10, after "it > > will need to reject these requests": In such cases, the SIP client > > shall reply to the requests with a 503 response without the Retry-After > header. >=20 > Bruno: Sorry for the delay. Catching up with pending email on SOC. >=20 > I had a look at Section 5.10.2 and Section 5.10 where you propose to add = the > above sentence. >=20 > S5.10 talks about a "SIP client" --- I am trying to figure out if we mean= t a > UAC or a proxy. >=20 > If this is a proxy, then the behaviour of that is already enumerated in > S5.10.2 using the same sentence you specify above. >=20 > If this is a UAC and it supports overload control, then it has already > received overload control feedback from the downstream overloaded server.= It > will act accordingly. >=20 > If this is a UAC and it does not support overload control, then it will s= imply > wait for a final response from the downstream server. The UAC, since it = does > not support overload control, will unfortunately keep sending requests > downstream. >=20 > As such, I am not sure if we need to add anything at all. But I am open = to > suggestions. >=20 > Thanks, >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From vkg@bell-labs.com Fri Mar 22 09:49:57 2013 Return-Path: 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 F225B21F8F08 for ; Fri, 22 Mar 2013 09:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 ZKb1h+ufMxdz for ; Fri, 22 Mar 2013 09:49:56 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3003421F8F06 for ; Fri, 22 Mar 2013 09:49:56 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r2MGnsO3021867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Mar 2013 11:49:54 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r2MGnsMm001425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Mar 2013 11:49:54 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r2MGnsBX016565; Fri, 22 Mar 2013 11:49:54 -0500 (CDT) Message-ID: <514C8C5B.30105@bell-labs.com> Date: Fri, 22 Mar 2013 11:52:43 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: bruno.chatras@orange.com References: <51110A56.7030402@ericsson.com> <51189F14.6050405@ericsson.com> <20305_1360573159_5118B2E6_20305_1921_3_88CAD1D4E8773F42858B58CAA28272A0109278@PEXCVZYM12.corporate.adroot.infra.ftgroup> <514C783E.8000907@bell-labs.com> <20666_1363970510_514C89CD_20666_96_1_88CAD1D4E8773F42858B58CAA28272A015CA29@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <20666_1363970510_514C89CD_20666_96_1_88CAD1D4E8773F42858B58CAA28272A015CA29@PEXCVZYM12.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 16:49:57 -0000 On 03/22/2013 11:41 AM, bruno.chatras@orange.com wrote: > Hi Vijay, > > I realize that the relation between my question and 5.10.2 was a bit > confusing. I had in mind the following scenario: > > A SIP Client (Proxy or a B2BUA) receives a request from a UAC and has > to forward it to an overloaded downstream server. This Proxy or B2BUA > has received overloaded control feedback from the overloaded server. > Because of that it has to reject some requests received from the > upstream UAC (It could also send it to another destination but as > mentioned in clause 5.10: "In many cases, however, it will need to > reject these requests"). > > So my question is: Which SIP response to send in this case? I assume > & "503 (Service Unavailable)" response without the Retry-After header > would be appropriate but I did not find it explicitly stated in the > document. Bruno: OK, I will update as you suggest. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From vkg@bell-labs.com Mon Mar 25 08:58:50 2013 Return-Path: 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 3D01721F8FFB for ; Mon, 25 Mar 2013 08:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 qS8NShiNcfBG for ; Mon, 25 Mar 2013 08:58:49 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 79BEE21F9000 for ; Mon, 25 Mar 2013 08:58:46 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r2PFwjnA017865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 25 Mar 2013 10:58:45 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r2PFwjhb002851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 25 Mar 2013 10:58:45 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r2PFwjnb006292 for ; Mon, 25 Mar 2013 10:58:45 -0500 (CDT) Message-ID: <515074E1.4020909@bell-labs.com> Date: Mon, 25 Mar 2013 11:01:37 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: sip-overload@ietf.org References: <51110A56.7030402@ericsson.com>, <51189F14.6050405@ericsson.com> <5EBD159DE88147488A3B1590E09001840353173DCBC2@njfpsrvexg2.research.att.com> In-Reply-To: <5EBD159DE88147488A3B1590E09001840353173DCBC2@njfpsrvexg2.research.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 15:58:50 -0000 On 02/17/2013 04:49 PM, NOEL, ERIC (ERIC C) wrote: > Salvatore, > > I read the document and have a few comments: Eric: Sorry for the delay; finishing up WGLC comments related to the draft. Please see inline. > - Typos: > + Section 5.4 page 12, second paragraph "... is larger than the value > stored value, ...." --> "... is larger than the stored value, ..." > + Section 6.2 page 18, 7th paragraph, "20% for 1s." --> "20% for > 0.5s" or "oc-validity=500" --> "oc-validity=1000" Fixed. Thanks for a close read. > - Questions: > + Section 4.1 page 6, 4th paragraph, why using SHOULD and not MUST to > describe the client behavior upon receiving a response with the oc > parameters filled in. This is in contrast with section 5.5 page 12, > first paragraph, where a SIP client MUST honor overload control > values it receives from downstream neighbors. Changed SHOULD to MUST. > + Section 4.4 page 8, 4th paragraph, following a sequence number > overflow, the server must reset the oc-seq parameter. Do we incur the > risk of having the client ignore all server requests with the new > oc-seq until oc-validity expires? Or does the client need to be able > to identify when oc-seq was reset? That is a good question. I think that this an exceptional case and probably best handled by alerting the implementer of this instead of trying to be prescriptive using rfc-2119 language. To that extent, I can add some explanatory text as the last paragraph of S4.4 as follows: Due to an overflow, client implementations should be prepared to receive an "oc-seq" parameter whose value is less than the previous value. Client implementations can handle this by continuing to perform overload control until the "oc-validity" related to the previous value of "oc-seq" parameter expires. If someone has a better way to handle this case, please let me know. > + Section 7, should there be any mention of draft-soc-overload-rate-control? draft-soc-overload-rate-control is mentioned already as a companion overload control scheme throughout the document. Thus I see no specific reason to mention it in S7. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/