From bruno.chatras@orange.com Thu Mar 1 08:10:57 2012 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 7756F21E8162 for ; Thu, 1 Mar 2012 08:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.759 X-Spam-Level: X-Spam-Status: No, score=-4.759 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_FR=0.35, 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 Mm8oAFk7MTHl for ; Thu, 1 Mar 2012 08:10:55 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3D65A21E8172 for ; Thu, 1 Mar 2012 08:10:55 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1ACBEA441E0 for ; Thu, 1 Mar 2012 17:12:23 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 07908A441DF for ; Thu, 1 Mar 2012 17:12:23 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 17:10:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF7C5.E09659D1" Date: Thu, 1 Mar 2012 17:10:52 +0100 Message-ID: <9ECCF01B52E7AB408A7EB8535264214103D71AEB@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip-overload] draft-ietf-soc-load-control-event-package-02.txt Thread-Index: Acz3xeAqok3mzsCQT6ujIZZrDglK5A== From: To: X-OriginalArrivalTime: 01 Mar 2012 16:10:53.0772 (UTC) FILETIME=[E0B8B0C0:01CCF7C5] Subject: [sip-overload] draft-ietf-soc-load-control-event-package-02.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: Thu, 01 Mar 2012 16:10:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF7C5.E09659D1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Charles, =20 I think there is something wrong with the XML schema in version -02 (Clause 7). The schema header is included twice but the actual fields (sip-id-type, method-type...) do not appear anymore! =20 =20 Best Regards, Bruno =20 /// =20 From: "SHEN, CHARLES" =20 To: "sip-overload at ietf.org" =20 Date: Tue, 10 Jan 2012 19:24:51 +0000 Hi all, =20 I've posted an updated version of the load control event package, incorporated the online/offline comments I've received so far, such as state-delta inclusion, terminology usage and miscellaneous other clarifications. Thanks to all who reviewed. Additional comments are welcome. =20 =20 Thanks and happy new year! =20 Charles =20 ------_=_NextPart_001_01CCF7C5.E09659D1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Charles,

I think there is something wrong = with the XML schema in version -02 (Clause 7). The schema header is included twice = but the actual fields (sip-id-type, method-type…) do not appear anymore! =

Best Regards,
Bruno

///

From: "SHEN, CHARLES" <cs4303 at att.com> =

To: "sip-overload at ietf.org" <sip-overload at ietf.org> =

Date: Tue, 10 Jan 2012 19:24:51 +0000 Hi all,

I've posted an updated version of the load control event package, = incorporated the online/offline comments I've received so far, such as state-delta = inclusion, terminology usage and miscellaneous other clarifications. Thanks to all = who reviewed. Additional comments are welcome.

Thanks and happy new year!

Charles

------_=_NextPart_001_01CCF7C5.E09659D1-- From salvatore.loreto@ericsson.com Thu Mar 1 09:57:04 2012 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 8BC2021E80DD for ; Thu, 1 Mar 2012 09:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.794 X-Spam-Level: X-Spam-Status: No, score=-109.794 tagged_above=-999 required=5 tests=[AWL=0.805, 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 Fcqellg7JRfg for ; Thu, 1 Mar 2012 09:57:03 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2D221E80DA for ; Thu, 1 Mar 2012 09:57:03 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-b8-4f4fb86e33e9 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 34.9C.01970.E68BF4F4; Thu, 1 Mar 2012 18:57:02 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Mar 2012 18:57:02 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B803E2321; Thu, 1 Mar 2012 19:57:01 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8FFB752396; Thu, 1 Mar 2012 19:57:01 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1BE7452171; Thu, 1 Mar 2012 19:57:01 +0200 (EET) Message-ID: <4F4FB86C.2030908@ericsson.com> Date: Thu, 1 Mar 2012 19:57:00 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "sip-overload@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: Volker Hilt Subject: [sip-overload] WGLC: draft-ietf-soc-overload-control 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, 01 Mar 2012 17:57:04 -0000 [as chair] the draft-ietf-soc-overload-control-07 includes all the changes that were agreed on the mailing list between Jan-04-2012 and Jan-16-2012 http://tools.ietf.org/html/draft-ietf-soc-overload-control-07 Volker and I, as chairs, believe the document has no remaining open issues, and it is ready for WG last call evaluation. Today we are starting a two-weeks working group last call. This call end on Thursday March 15th. Comments and especially full and deep reviews of the draft are really appreciate. cheers Sal Ciao Salvatore Loreto www.sloreto.com From cs4303@att.com Fri Mar 2 09:05:32 2012 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 6225521F86D7 for ; Fri, 2 Mar 2012 09:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 2Yiy8Eya1jyL for ; Fri, 2 Mar 2012 09:05:31 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id E33A921F86C8 for ; Fri, 2 Mar 2012 09:05:30 -0800 (PST) X-Env-Sender: cs4303@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1330707929!65714065!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21865 invoked from network); 2 Mar 2012 17:05:30 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-5.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Mar 2012 17:05:30 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q22H5xq3015526; Fri, 2 Mar 2012 12:06:00 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q22H5tUn015445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Mar 2012 12:05:55 -0500 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by sflint01.pst.cso.att.com (RSA Interceptor); Fri, 2 Mar 2012 12:05:16 -0500 Received: from MISOUT7MSGUSR9A.ITServices.sbc.com ([169.254.1.132]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.01.0355.002; Fri, 2 Mar 2012 12:05:16 -0500 From: "SHEN, CHARLES" To: "'bruno.chatras@orange.com'" Thread-Topic: [sip-overload] draft-ietf-soc-load-control-event-package-02.txt Thread-Index: Acz3xeAqok3mzsCQT6ujIZZrDglK5AAyg7kA Date: Fri, 2 Mar 2012 17:05:15 +0000 Message-ID: <9EC99DA9F107DF4A8AD7B332FB5FC5CD016BE8C2@MISOUT7MSGUSR9A.ITServices.sbc.com> References: <9ECCF01B52E7AB408A7EB8535264214103D71AEB@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214103D71AEB@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.109.8.199] Content-Type: multipart/alternative; boundary="_000_9EC99DA9F107DF4A8AD7B332FB5FC5CD016BE8C2MISOUT7MSGUSR9A_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: "'sip-overload@ietf.org'" Subject: Re: [sip-overload] draft-ietf-soc-load-control-event-package-02.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, 02 Mar 2012 17:05:32 -0000 --_000_9EC99DA9F107DF4A8AD7B332FB5FC5CD016BE8C2MISOUT7MSGUSR9A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bruno, Thank you for spotting this! This appears to have been caused by a formatti= ng issue when I added the delta-support to the schema. I will fix it and su= bmit a new version later today. Thanks Charles From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of bruno.chatras@orange.com Sent: Thursday, March 01, 2012 11:11 AM To: sip-overload@ietf.org Subject: [sip-overload] draft-ietf-soc-load-control-event-package-02.txt Charles, I think there is something wrong with the XML schema in version -02 (Clause= 7). The schema header is included twice but the actual fields (sip-id-type= , method-type...) do not appear anymore! Best Regards, Bruno /// From: "SHEN, CHARLES" To: "sip-overload at ietf.org" Date: Tue, 10 Jan 2012 19:24:51 +0000 Hi all, I've posted an updated version of the load control event package, incorpora= ted the online/offline comments I've received so far, such as state-delta i= nclusion, terminology usage and miscellaneous other clarifications. Thanks = to all who reviewed. Additional comments are welcome. Thanks and happy new year! Charles --_000_9EC99DA9F107DF4A8AD7B332FB5FC5CD016BE8C2MISOUT7MSGUSR9A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Bruno,

= Thank you for spotting this!= This appears to have been caused by a formatting issue when I added the de= lta-support to the schema. I will fix it and submit a new version later today.

= Thanks

= Charles

From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of bruno.chatras@orange.com
Sent: Thursday, March 01, 20= 12 11:11 AM
To: sip-overload@ietf.org Subject: [sip-overload] draf= t-ietf-soc-load-control-event-package-02.txt

Charles,

I think there is something wrong with the XML schema in vers= ion -02 (Clause 7). The schema header is included twice but the actual fiel= ds (sip-id-type, method-type…) do not appear anymore!

Best Regards,
Bruno

///

From: "SHEN, CH= ARLES" <cs4303 at att.com>

To: "sip-overlo= ad at ietf.org" <sip-overload at ietf.org>

Date: Tue, 10 Jan 20= 12 19:24:51 +0000 Hi all,

I've posted an updat= ed version of the load control event package, incorporated the online/offli= ne comments I've received so far, such as state-delta inclusion, terminology usage and miscellaneous other clarifications. Thank= s to all who reviewed. Additional comments are welcome.

Thanks and happy new= year!

Charles<= o:p>

--_000_9EC99DA9F107DF4A8AD7B332FB5FC5CD016BE8C2MISOUT7MSGUSR9A_-- From internet-drafts@ietf.org Fri Mar 2 09:28:43 2012 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 3AE3921E8017; Fri, 2 Mar 2012 09:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 P690dexhBJmp; Fri, 2 Mar 2012 09:28:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7591C21F853B; Fri, 2 Mar 2012 09:28:20 -0800 (PST) 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.00 Message-ID: <20120302172820.2510.62076.idtracker@ietfa.amsl.com> Date: Fri, 02 Mar 2012 09:28:20 -0800 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-load-control-event-package-03.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, 02 Mar 2012 17:28:43 -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-03.txt Pages : 35 Date : 2012-03-02 We define a load control event package for the Session Initiation Protocol (SIP). It allows SIP servers to distribute load filters to other SIP servers in the network. The load filters 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-soc-load-control-event-packa= ge-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-soc-load-control-event-packag= e-03.txt From emcmurry@estacado.net Wed Mar 7 11:10:57 2012 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 4207311E8072 for ; Wed, 7 Mar 2012 11:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=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 X3czgyu3hadu for ; Wed, 7 Mar 2012 11:10:56 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id 626BF21F85AA for ; Wed, 7 Mar 2012 11:10:56 -0800 (PST) Received: from dn3-227.estacado.net (dn3-227.estacado.net [172.16.3.227]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q27JAr1p096554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 7 Mar 2012 13:10:55 -0600 (CST) (envelope-from emcmurry@estacado.net) From: Eric McMurry Content-Type: multipart/alternative; boundary="Apple-Mail=_654FFEAB-C44A-4038-9F20-48DB3D4E4864" Date: Wed, 7 Mar 2012 13:10:53 -0600 Message-Id: To: sip-overload@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [sip-overload] draft-ietf-soc-overload-control-07 section 6.3 algorithm 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: Wed, 07 Mar 2012 19:10:57 -0000 --Apple-Mail=_654FFEAB-C44A-4038-9F20-48DB3D4E4864 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm a bit confused on the default loss-based algorithm in section 6.3 of = draft-ietf-soc-overload-control-07. Based on the text, I believe that = this algorithm is intended to apply to outbound messages from a client = and to use previously stored information about the overload condition of = the downstream server the message is targeted to. When I read through the algorithm part though, I'm not sure of the = intent. I've made some changes in the algorithm to try to communicate = what I think it was saying. Does this match the intent? cat1 :=3D 40.0 // Category 1 --- subject to reduction cat2 :=3D 100.0 - cat1 // Category 2 --- Not subject to // reduction. 40/60 mix. in_oc :=3D false // Not operating under overload while (true) { sip_msg :=3D get_outgoing_sip_msg() if (is_response(sip_msg)) { process_msg(sip_msg) } else if (is_request(sip_msg)) { // Determine if target server wants to enter overload or is // in overload target_server :=3D extract_target(sip_msg) in_oc :=3D lookup_in_oc(target_server) // Get validity value oc_validity :=3D lookup_oc_validity(target_server) // Get oc parameter value oc_value :=3D lookup_oc_value(target_server) pct_to_reduce :=3D oc_value / cat1 * 100 // Example: if oc=3D10, // server uses 10 / 40 * 100 =3D 25 or 25% of messages in // Category 1 can be reduced. if (in_oc =3D=3D false) { process_msg(sip_msg) } else { // Either Category 1 or Category 2 assign_msg_to_category(sip_msg) if (oc_validity is in effect) { process_msg(get_msg_from_cat2()) sip_msg :=3D get_msg_from_cat1() // Draw a random number between 1 and 100 r :=3D random() if (r <=3D pct_to_reduce) { // Do not send to server, handle locally by // generating a final response } else { process_msg(sip_msg) } } } } } --Apple-Mail=_654FFEAB-C44A-4038-9F20-48DB3D4E4864 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

I'm a bit confused on the default loss-based algorithm in =
section 6.3 of draft-ietf-soc-overload-control-07.  Based on the =
text, I believe that this algorithm is intended to apply to outbound =
messages from a client and to use previously stored information about =
the overload condition of the downstream server the message is targeted =
to.

When I read =
through the algorithm part though, I'm not sure of the intent. =
 I've made some changes in the algorithm to try to communicate what =
I think it was saying.  Does this match the =
intent?

    cat1 :=3D 40.0       =
   // Category 1 --- subject to reduction
   cat2 :=3D 100.0 - cat1  // Category 2 --- Not subject to
                         // reduction.  40/60 mix.
   in_oc :=3D false        // Not operating under overload

   while (true)  {
     sip_msg :=3D get_outgoing_sip_msg()
     if (is_response(sip_msg))  {
         process_msg(sip_msg)
     }
     else if (is_request(sip_msg))  {

       // Determine if target server wants to enter overload or is
       // in overload

       target_server :=3D =
extract_target(sip_msg)

       in_oc =
:=3D lookup_in_oc(target_server)

       // Get validity value
       oc_validity :=3D lookup_oc_validity(target_server)

       // Get oc parameter value
       oc_value :=3D lookup_oc_value(target_server)

       pct_to_reduce :=3D oc_value / cat1 * 100
       // Example: if oc=3D10,
       // server uses 10 / 40 * 100 =3D 25 or 25% of messages in
       // Category 1 can be reduced.

       if (in_oc =3D=3D false)  {
         process_msg(sip_msg)
       }
       else  {

         // Either Category 1 or Category 2
         assign_msg_to_category(sip_msg)

         if (oc_validity is in effect)  {
           process_msg(get_msg_from_cat2())
           sip_msg :=3D get_msg_from_cat1()

           // Draw a random number between 1 and 100
           r :=3D random()

           if (r <=3D pct_to_reduce)  {
               // Do not send to server, handle locally by
               // generating a final response
           }
           else  {
             process_msg(sip_msg)

= --Apple-Mail=_654FFEAB-C44A-4038-9F20-48DB3D4E4864-- From adam@nostrum.com Wed Mar 7 11:13:19 2012 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 EA7E611E8072 for ; Wed, 7 Mar 2012 11:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, SPF_PASS=-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 rQ3X0Bbwf94P for ; Wed, 7 Mar 2012 11:13:19 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD9321F85AA for ; Wed, 7 Mar 2012 11:13:18 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q27JD6tk082593 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Mar 2012 13:13:08 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4F57B342.2000209@nostrum.com> Date: Wed, 07 Mar 2012 13:13:06 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Salvatore Loreto References: <4F4FB86C.2030908@ericsson.com> In-Reply-To: <4F4FB86C.2030908@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Volker Hilt , "sip-overload@ietf.org" Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-control 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: Wed, 07 Mar 2012 19:13:20 -0000 I'm a bit confused by the algorithm described in section 6.3. First, it's not clear whether this is intended to apply to outbound messages (i.e., "get_sip_msg" is getting a message from an internal queue of things to be sent on the network) or inbound messages (i.e., "get_sip_msg" is getting a message from the network for processing). The introduction to 6.3 obliquely hints that it might be for outbound messages, but it's not really all that clear. In any case, the pseudocode starts: > cat1 := 40.0 // Category 1 --- subject to reduction > cat2 := 100.0 - cat1 // Category 2 --- Not subject to > // reduction. 40/60 mix. > in_oc := false // Not operating under overload > > while (true) { > sip_msg := get_sip_msg() > if (is_response(sip_msg)) { > process_msg(sip_msg) > } > else if (is_request(sip_msg)) { > > // Determine if server wants to enter overload or is > // in overload > in_oc := extract_in_oc(sip_msg) > > // Get validity value > oc_validity := extract_oc_validity(sip_msg) > > // Get oc parameter value > oc_value := extract_oc_value(sip_msg) > > pct_to_reduce := oc_value / cat1 * 100 > // Example: if oc=10, > // server uses 10 / 40 * 100 = 25 or 25% of messages in > // Category 1 can be reduced. > ... If you make assumptions about functions based on their names, this attempts to extract oc value and oc validity information from the SIP *request* messages. My reading of the rest of this document is that *requests* will only have an empty, bare "oc" parameter in them. The actual overload control information appears in *responses*. Right? On the other hand, if this is really for outbound messages, then what you need to do is store the OC data received from inbound responses (which would be in a processing loop not shown here), and the handling for outbound messages would really be computing the destination and then looking up any overload information that might have been stored for that destination. Right? There's also the rather confusing bit here: > > // Either Category 1 or Category 2 > assign_msg_to_category(sip_msg) > > if (oc_validity is in effect) { > process_msg(get_msg_from_cat2()) > sip_msg := get_msg_from_cat1() > > // Draw a random number between 1 and 100 > r := random() > > if (r <= pct_to_reduce) { > // Do not send to server, handle locally by > // generating a final response > } > else { > process_msg(sip_msg) > } Is the intention here that the message, if it is in category 2, is always sent, while the message, if it is in category 1, is subject to the shaping rules? If so, this seems a rather baroque way to effect that. Don't you mean something more like: // Either Category 1 or Category 2 category := assign_msg_to_category(sip_msg) if (oc_validity is in effect) { if (category == 2) { process_msg(sip_msg) } else { // Draw a random number between 1 and 100 r := random() if (r <= pct_to_reduce) { // Do not send to server, handle locally by // generating a final response } else { process_msg(sip_msg) } Except that's not quite right, since oc can be larger than cat 1. For example, if we use the 40/60 mix you have in the draft, your proposed amount to reduce looks like: pct_to_reduce := oc_value / cat1 * 100 pct_to_reduce := 50 / 40 * 100 pct_to_reduce := 125 Of course, a 125% reduction in category 1 messages isn't possible, so you're forced into reduction of category 2 messages. In other words, you need to calculate pct_to_reduce based on the message type, and take appropriate action when oc > cat1. Finally, if you look at the codepath where "in_oc" is true but "oc_validity is in effect" is false, then the message is never processed. I think you really want to combine these into a single logical statement like: if (in_oc == false && oc_validity is in effect) { send_message_to_network(sip_msg) } So, taking the above assumptions into account, I think you really want something that looks more like: cat1 := 40.0 // Category 1 --- subject to reduction cat2 := 100.0 - cat1 // Category 2 --- Not subject to // reduction. 40/60 mix. in_oc := false // Not operating under overload while (true) { sip_msg := get_outbound_sip_msg() if (is_response(sip_msg)) { if (sip_msg.via has oc parameter)) { add_overload_metrics(sip_msg) } send_message_to_network(sip_msg) } else if (is_request(sip_msg)) { destination := get_next_hop(sip_msg) // Determine if server wants to enter overload or is // in overload in_oc := lookup_in_oc(destination) // Get validity value oc_validity := lookup_oc_validity(destination) // Get oc parameter value oc_value := lookup_oc_value(destination) if (in_oc == false or oc_validity is not in effect) { send_message_to_network(sip_msg) } else { // Either Category 1 or Category 2 category := assign_msg_to_category(sip_msg) if (category == 1) { pct_to_reduce := min (oc_value / cat1 * 100, 100) // Example: if oc=10, // server uses 10 / 40 * 100 = 25 or 25% of messages in // Category 1 can be reduced. } else { pct_to_reduce := max(0, oc_value / cat1 * 100 - 100) // Example: if oc=50, // server uses 50 / 40 * 100 - 100 = 25 or 25% of messages in // Category 2 can be reduced. } // Draw a random number between 1 and 100 r := random() if (r <= pct_to_reduce) { // Do not send to server, handle locally by // generating a final response } else { send_message_to_network(sip_msg) } } } } From adam@nostrum.com Wed Mar 7 11:14:30 2012 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 9F43611E8072 for ; Wed, 7 Mar 2012 11:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.053 X-Spam-Level: X-Spam-Status: No, score=-102.053 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, SPF_PASS=-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 pR2rmXmCZLa1 for ; Wed, 7 Mar 2012 11:14:29 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AB2AD21F85AA for ; Wed, 7 Mar 2012 11:14:29 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q27JERnm082739 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Mar 2012 13:14:28 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4F57B393.3020702@nostrum.com> Date: Wed, 07 Mar 2012 13:14:27 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Eric McMurry References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030901000807080508050504" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-control-07 section 6.3 algorithm 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: Wed, 07 Mar 2012 19:14:30 -0000 This is a multi-part message in MIME format. --------------030901000807080508050504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sigh. Eric and I have been discussing this just now, and we got our messages crossed. He fixed one of about four problems with his changes below. See my message of about 2 minutes ago for a proposal that fixes several other issues. /a On 3/7/12 1:10 PM, Eric McMurry wrote: > I'm a bit confused on the default loss-based algorithm in section 6.3 of draft-ietf-soc-overload-control-07. Based on the text, I believe that this algorithm is intended to apply to outbound messages from a client and to use previously stored information about the overload condition of the downstream server the message is targeted to. > > When I read through the algorithm part though, I'm not sure of the intent. I've made some changes in the algorithm to try to communicate what I think it was saying. Does this match the intent? > cat1 := 40.0 // Category 1 --- subject to reduction > cat2 := 100.0 - cat1 // Category 2 --- Not subject to > // reduction. 40/60 mix. > in_oc := false // Not operating under overload > > while (true) { > sip_msg := get_outgoing_sip_msg() > if (is_response(sip_msg)) { > process_msg(sip_msg) > } > else if (is_request(sip_msg)) { > > // Determine iftarget server wants to enter overload or is > // in overload > target_server := extract_target(sip_msg) > in_oc :=lookup_in_oc(target_server) > > // Get validity value > oc_validity :=lookup_oc_validity(target_server) > > // Get oc parameter value > oc_value :=lookup_oc_value(target_server) > > pct_to_reduce := oc_value / cat1 * 100 > // Example: if oc=10, > // server uses 10 / 40 * 100 = 25 or 25% of messages in > // Category 1 can be reduced. > > if (in_oc == false) { > process_msg(sip_msg) > } > else { > > // Either Category 1 or Category 2 > assign_msg_to_category(sip_msg) > > if (oc_validity is in effect) { > process_msg(get_msg_from_cat2()) > sip_msg := get_msg_from_cat1() > > // Draw a random number between 1 and 100 > r := random() > > if (r<= pct_to_reduce) { > // Do not send to server, handle locally by > // generating a final response > } > else { > process_msg(sip_msg) > } > } > } > } > } > > > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload --------------030901000807080508050504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sigh. Eric and I have been discussing this just now, and we got our messages crossed. He fixed one of about four problems with his changes below. See my message of about 2 minutes ago for a proposal that fixes several other issues.

/a

On 3/7/12 1:10 PM, Eric McMurry wrote:

I'm a bit confused on the default loss-based algorithm in section 6.3 of draft-ietf-soc-overload-control-07.  Based on the text, I believe that this algorithm is intended to apply to outbound messages from a client and to use previously stored information about the overload condition of the downstream server the message is targeted to.

When I read through the algorithm part though, I'm not sure of the intent.  I've made some changes in the algorithm to try to communicate what I think it was saying.  Does this match the intent?

    cat1 := 40.0          // Category 1 --- subject to reduction
   cat2 := 100.0 - cat1  // Category 2 --- Not subject to
                         // reduction.  40/60 mix.
   in_oc := false        // Not operating under overload

   while (true)  {
     sip_msg := get_outgoing_sip_msg()
     if (is_response(sip_msg))  {
         process_msg(sip_msg)
     }
     else if (is_request(sip_msg))  {

       // Determine if target server wants to enter overload or is
       // in overload

       target_server := extract_target(sip_msg)

       in_oc := lookup_in_oc(target_server)

       // Get validity value
       oc_validity := lookup_oc_validity(target_server)

       // Get oc parameter value
       oc_value := lookup_oc_value(target_server)

       pct_to_reduce := oc_value / cat1 * 100
       // Example: if oc=10,
       // server uses 10 / 40 * 100 = 25 or 25% of messages in
       // Category 1 can be reduced.

       if (in_oc == false)  {
         process_msg(sip_msg)
       }
       else  {

         // Either Category 1 or Category 2
         assign_msg_to_category(sip_msg)

         if (oc_validity is in effect)  {
           process_msg(get_msg_from_cat2())
           sip_msg := get_msg_from_cat1()

           // Draw a random number between 1 and 100
           r := random()

           if (r <= pct_to_reduce)  {
               // Do not send to server, handle locally by
               // generating a final response
           }
           else  {
             process_msg(sip_msg)

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

--------------030901000807080508050504-- From vkg@bell-labs.com Thu Mar 8 10:03:48 2012 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 0001A21F86DF for ; Thu, 8 Mar 2012 10:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.929 X-Spam-Level: X-Spam-Status: No, score=-108.929 tagged_above=-999 required=5 tests=[AWL=1.670, 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 5D0gXFL3126b for ; Thu, 8 Mar 2012 10:03:47 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id E928C21F85CC for ; Thu, 8 Mar 2012 10:03:46 -0800 (PST) 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 q28I3k2s014333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 8 Mar 2012 12:03:46 -0600 (CST) 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 q28I3j7x023278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 8 Mar 2012 12:03:46 -0600 Received: from shoonya.ih.lucent.com (shoonya-135185238235.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q28I3jDR028285 for ; Thu, 8 Mar 2012 12:03:45 -0600 (CST) Message-ID: <4F58F595.9070107@bell-labs.com> Date: Thu, 08 Mar 2012 12:08:21 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: sip-overload@ietf.org References: <4F57B393.3020702@nostrum.com> In-Reply-To: <4F57B393.3020702@nostrum.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.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [sip-overload] draft-ietf-soc-overload-control-07 section 6.3 algorithm 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, 08 Mar 2012 18:03:48 -0000 Adam, Eric: Thank you for looking over the algorithm. I was hoping that more eyeballs will look at it and uncover problems. The baroqueness you refer to is an artefact of trying to come up with a cohesive algorithm based on a simple textual description [1] coupled with ensuing discussions on the list on how to specify local policy when the server is overloaded and bolstered by some underlying unstated assumptions. In any case, I have modified the algorithm based on your suggested changes with unstated assumptions filled out, for instance, in the algorithm below, I have included more details on message prioritization that occurs for category 2 messages under overload. In the ealier iteration, I had simply stated in text that if there are not enough messages in category 1, then client may use "local policies" to target messages in category 2. With the algorithm relatively fresh in our minds, let's see if what appears below addresses your comments. Note that I have also fixed category 1 / category 2 messages to be a 80/20 mix instead of a 40/60 mix earlier. It seems appropriate that the corpus of messages that are subject to reduction be more than those that are not (unless an emergency situation is occurring). Thank you for pointing out where the errors lie! Please take a look at the updated algorithm below and lets see if we can work at making this any better. cat1 := 80.0 // Category 1 --- subject to reduction cat2 := 100.0 - cat1 // Category 2 --- Not subject to reduction // 80/20 mix. while (true) { sip_msg := get_sip_msg() // Next SIP message to process, could be a // request or a response if (is_response(sip_msg)) { if (sip_msg has oc parameter values) { create_or_update_oc_context() // For the specific server // that sent the response, create or update the oc context; // i.e., extract the values of the oc-related parameters // and store them for later use. } process_msg(sip_msg) // Rest of normal processing occurs on // the response, which may include consuming it if the client // is a user agent or sending it upstream if a proxy } else if (is_request(sip_msg)) { destination := get_next_hop(sip_msg) oc_context := get_oc_context(destination) if (oc_context == null) { process_msg(sip_msg) // Process it normally by sending the // request downstream since this particular destination // is not subject to overload } else { // Determine if server wants to enter in overload or is in // overload in_oc := extract_in_oc(oc_context) oc_value := extract_oc(oc_context) oc_validity := extract_oc_validity(oc_context) if (in_oc == false or oc_validity is not in effect) { process_msg(sip_msg) // Process it normally by sending the // request downstream since this particular destination // is not subject to overload. Optionally, clear // the oc context for this server (not shown). } else { category := assign_msg_to_category(sip_msg) drop_msg := 0 pct_to_reduce := min(100, oc_value / cat1 * 100) r := random() if (r <= pct_to_reduce) { drop_msg := 1 } if (category == cat2 && drop_msg == 1) { if (local_policy(sip_msg, oc_value) says process message) { drop_msg := 0 // See Note 1 below } } if (drop_msg == 0) { process_msg(sip_msg) // Process it normally by sending // the request downstream } else { // Do not send request downstream, handle locally by // generating response. } } } } // is_request(sip_msg) } Note 1: local_policy() will have to decide whether to allow a category 2 request downstream if that request has been marked for discard. Some discussion on how to make this decision is captured in Section 5.10.1. There will be four cases to consider in figuring out how local_policy() should behave. These are enunciated below, and in these cases, t is the inter-invocation time of local_policy() and oc is the value of the "oc" parameter. Case 1: t is small (<= 10 times/sec?) and oc is small (<20%?) Case 2: t is large (>= 500 times/sec?) and oc is large (>70%?) Case 3: t is small and oc is large Case 4: t is large and oc is small The decision in cases 1 and 3 seems simple. In case 1, local_policy() is not invoked as often and the oc value is small. On the few times that local_policy() is invoked, it could allow the request to to be sent to the server. In case 3, local_policy() is not invoked as often but the oc value is large. This implies that there are enough category 1 messages that are being dropped. On the few times that local_policy() is invoked, it could allow the request to be sent to the server. It is cases 2 and 4 that local_policy() should do something more intelligent. In case 2, local_policy() is getting invoked very often and the oc is also large. This implies that category 1 requests are being dropped as much as possible and it will help to drop a good number of category 2 requests as well. Thus, it seems reasonable to drop all but the SOS URN [RFC5031] requests and high priority RPH content requests. In case 4, local_policy() is getting invoked very often, but the oc value is small. This implies that the bulk of traffic to be dropped consists of category 2 requests. So here, it seems reasonable to drop all but the SOS URN [RFC5031] requests. [1] www.ietf.org/mail-archive/web/sip-overload/current/msg00318.html 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 adam@nostrum.com Thu Mar 8 10:30:38 2012 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 97E3221F86B3 for ; Thu, 8 Mar 2012 10:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, SPF_PASS=-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 60f6yIkhHQjZ for ; Thu, 8 Mar 2012 10:30:37 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AC08F21F86A4 for ; Thu, 8 Mar 2012 10:30:37 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q28IUZPH006160 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Mar 2012 12:30:35 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4F58FACB.2020602@nostrum.com> Date: Thu, 08 Mar 2012 12:30:35 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <4F57B393.3020702@nostrum.com> <4F58F595.9070107@bell-labs.com> In-Reply-To: <4F58F595.9070107@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-control-07 section 6.3 algorithm 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, 08 Mar 2012 18:30:38 -0000 No, now I'm even more confused. I have a rather long list of things I think need to change here, but I don't want to throw them all out for fear of them being confused with each other. Let's start simple, with the most fundamentally important question: where is "get_sip_msg()" getting a message from? (a) Some internal queue of outgoing SIP messages to be sent to the network (b) A network interface (or some abstraction thereof) representing incoming SIP messages (c) Somewhere else /a On 3/8/12 12:08 PM, Vijay K. Gurbani wrote: > Adam, Eric: Thank you for looking over the algorithm. I was hoping > that more eyeballs will look at it and uncover problems. The > baroqueness you refer to is an artefact of trying to come up with > a cohesive algorithm based on a simple textual description [1] coupled > with ensuing discussions on the list on how to specify local policy when > the server is overloaded and bolstered by some underlying unstated > assumptions. > > In any case, I have modified the algorithm based on your suggested > changes with unstated assumptions filled out, for instance, > in the algorithm below, I have included more details on message > prioritization that occurs for category 2 messages under overload. > In the ealier iteration, I had simply stated in text that if there > are not enough messages in category 1, then client may use > "local policies" to target messages in category 2. > > With the algorithm relatively fresh in our minds, let's see if what > appears below addresses your comments. Note that I have also fixed > category 1 / category 2 messages to be a 80/20 mix instead of a > 40/60 mix earlier. It seems appropriate that the corpus of messages > that are subject to reduction be more than those that are not (unless > an emergency situation is occurring). > > Thank you for pointing out where the errors lie! Please take a look > at the updated algorithm below and lets see if we can work at making > this any better. > > cat1 := 80.0 // Category 1 --- subject to reduction > cat2 := 100.0 - cat1 // Category 2 --- Not subject to reduction > // 80/20 mix. > while (true) { > sip_msg := get_sip_msg() // Next SIP message to process, could be a > // request or a response > > if (is_response(sip_msg)) { > if (sip_msg has oc parameter values) { > create_or_update_oc_context() // For the specific server > // that sent the response, create or update the oc context; > // i.e., extract the values of the oc-related parameters > // and store them for later use. > } > process_msg(sip_msg) // Rest of normal processing occurs on > // the response, which may include consuming it if the client > // is a user agent or sending it upstream if a proxy > } > else if (is_request(sip_msg)) { > destination := get_next_hop(sip_msg) > oc_context := get_oc_context(destination) > > if (oc_context == null) { > process_msg(sip_msg) // Process it normally by sending the > // request downstream since this particular destination > // is not subject to overload > } > else { > // Determine if server wants to enter in overload or is in > // overload > in_oc := extract_in_oc(oc_context) > > oc_value := extract_oc(oc_context) > oc_validity := extract_oc_validity(oc_context) > > if (in_oc == false or oc_validity is not in effect) { > process_msg(sip_msg) // Process it normally by sending the > // request downstream since this particular destination > // is not subject to overload. Optionally, clear > // the oc context for this server (not shown). > } > else { > category := assign_msg_to_category(sip_msg) > drop_msg := 0 > pct_to_reduce := min(100, oc_value / cat1 * 100) > > r := random() > if (r <= pct_to_reduce) { > drop_msg := 1 > } > > if (category == cat2 && drop_msg == 1) { > if (local_policy(sip_msg, oc_value) says process > message) { > drop_msg := 0 // See Note 1 below > } > } > > if (drop_msg == 0) { > process_msg(sip_msg) // Process it normally by sending > // the request downstream > } > else { > // Do not send request downstream, handle locally by > // generating response. > } > } > } > } // is_request(sip_msg) > } > > Note 1: local_policy() will have to decide whether to allow a category > 2 request downstream if that request has been marked for discard. > Some discussion on how to make this decision is captured in Section > 5.10.1. > > There will be four cases to consider in figuring out how local_policy() > should behave. These are enunciated below, and in these cases, t is > the inter-invocation time of local_policy() and oc is the value of > the "oc" parameter. > > Case 1: t is small (<= 10 times/sec?) and oc is small (<20%?) > Case 2: t is large (>= 500 times/sec?) and oc is large (>70%?) > Case 3: t is small and oc is large > Case 4: t is large and oc is small > > The decision in cases 1 and 3 seems simple. In case 1, local_policy() > is not invoked as often and the oc value is small. On the few > times that local_policy() is invoked, it could allow the request to > to be sent to the server. > > In case 3, local_policy() is not invoked as often but the oc value > is large. This implies that there are enough category 1 messages > that are being dropped. On the few times that local_policy() is > invoked, it could allow the request to be sent to the server. > > It is cases 2 and 4 that local_policy() should do something more > intelligent. > > In case 2, local_policy() is getting invoked very > often and the oc is also large. This implies that category 1 > requests are being dropped as much as possible and it will help > to drop a good number of category 2 requests as well. Thus, > it seems reasonable to drop all but the SOS URN [RFC5031] > requests and high priority RPH content requests. > > In case 4, local_policy() is getting invoked very often, but the > oc value is small. This implies that the bulk of traffic to be > dropped consists of category 2 requests. So here, it seems > reasonable to drop all but the SOS URN [RFC5031] requests. > > [1] www.ietf.org/mail-archive/web/sip-overload/current/msg00318.html > > Thanks, > > - vijay From vkg@bell-labs.com Thu Mar 8 11:00:25 2012 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 9BB8021F8535 for ; Thu, 8 Mar 2012 11:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.958 X-Spam-Level: X-Spam-Status: No, score=-106.958 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 txly7TE0VmIY for ; Thu, 8 Mar 2012 11:00:24 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 95E8821F846C for ; Thu, 8 Mar 2012 11:00:24 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q28J0MiA016012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Mar 2012 13:00:22 -0600 (CST) 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 q28J0L6s023203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Mar 2012 13:00:22 -0600 Received: from shoonya.ih.lucent.com (shoonya-135185238235.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q28J0LOf012622; Thu, 8 Mar 2012 13:00:21 -0600 (CST) Message-ID: <4F5902D9.1080006@bell-labs.com> Date: Thu, 08 Mar 2012 13:04:57 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: Adam Roach References: <4F57B393.3020702@nostrum.com> <4F58F595.9070107@bell-labs.com> <4F58FACB.2020602@nostrum.com> In-Reply-To: <4F58FACB.2020602@nostrum.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.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-control-07 section 6.3 algorithm 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, 08 Mar 2012 19:00:25 -0000 On 03/08/2012 12:30 PM, Adam Roach wrote: > No, now I'm even more confused. I have a rather long list of things I > think need to change here, but I don't want to throw them all out for > fear of them being confused with each other. > > Let's start simple, with the most fundamentally important question: > where is "get_sip_msg()" getting a message from? > > (a) Some internal queue of outgoing SIP messages to be sent to the network > (b) A network interface (or some abstraction thereof) representing > incoming SIP messages > (c) Somewhere else So I fail to see the need to pin down exactly where it is getting these messages from? From the processing point of view, the algorithm (being executed at a client upstream of the overloaded server) gets a SIP message and it has to decide if it is a request or response. The host executing this algorithm could be a UAC, in which case it is getting SIP responses from the network and it is getting SIP requests from its TU. Or, that host could be a proxy, in which case it is getting (in a sense) both requests and responses from the network. If a response, the algorithm extracts the oc parameters and creates the oc context for the server that filled in the oc parameters. If it is a request, it decides whether the request is destined to server that indicated oc before. We can chat over the phone if that will make the convergence process faster? - 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 adam@nostrum.com Thu Mar 8 11:12:34 2012 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 E1F3021F853A for ; Thu, 8 Mar 2012 11:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, SPF_PASS=-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 eeisdkiJ8tqq for ; Thu, 8 Mar 2012 11:12:34 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC7A21F8534 for ; Thu, 8 Mar 2012 11:12:34 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q28JCW9L012726 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Mar 2012 13:12:33 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4F5904A0.5090709@nostrum.com> Date: Thu, 08 Mar 2012 13:12:32 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <4F57B393.3020702@nostrum.com> <4F58F595.9070107@bell-labs.com> <4F58FACB.2020602@nostrum.com> <4F5902D9.1080006@bell-labs.com> In-Reply-To: <4F5902D9.1080006@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-control-07 section 6.3 algorithm 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, 08 Mar 2012 19:12:35 -0000 On 3/8/12 1:04 PM, Vijay K. Gurbani wrote: > On 03/08/2012 12:30 PM, Adam Roach wrote: >> No, now I'm even more confused. I have a rather long list of things I >> think need to change here, but I don't want to throw them all out for >> fear of them being confused with each other. >> >> Let's start simple, with the most fundamentally important question: >> where is "get_sip_msg()" getting a message from? >> >> (a) Some internal queue of outgoing SIP messages to be sent to the >> network >> (b) A network interface (or some abstraction thereof) representing >> incoming SIP messages >> (c) Somewhere else > > So I fail to see the need to pin down exactly where it is getting > these messages from? Because responses that you're *sending* will *not* contain overload information that you need to extract. In fact, you'll need to take action to *put* overload information in them. Responses that you're *receiving* will potentially contain overload information that you need to extract and store. Similarly, requests that you're about to *send* are subject to the overload state of their next hop host, and might be dropped accordingly. Requests that you've just *received* aren't (although they might be subject to local rejection, per the behavior in 5.10.2). Critically, there are four different behaviors that need to be detailed: inbound request, outbound request, inbound response, and outbound response. The algorithm in the draft (and the revised one that you proposed) seem to mash these all together into two cases (request and response), which are then slightly or radically wrong, depending on whether they're applied to inbound or outbound messages. /a From vkg@bell-labs.com Thu Mar 8 11:25:40 2012 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 2847B21E801B for ; Thu, 8 Mar 2012 11:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.952 X-Spam-Level: X-Spam-Status: No, score=-106.952 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 rcj0Cves-pkV for ; Thu, 8 Mar 2012 11:25:39 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 676C521E8018 for ; Thu, 8 Mar 2012 11:25:39 -0800 (PST) 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 q28JPYsg016942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Mar 2012 13:25:34 -0600 (CST) 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 q28JPYii016207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Mar 2012 13:25:34 -0600 Received: from shoonya.ih.lucent.com (shoonya-135185238235.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q28JPXSw003678; Thu, 8 Mar 2012 13:25:34 -0600 (CST) Message-ID: <4F5908C1.8060709@bell-labs.com> Date: Thu, 08 Mar 2012 13:30:09 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: Adam Roach References: <4F57B393.3020702@nostrum.com> <4F58F595.9070107@bell-labs.com> <4F58FACB.2020602@nostrum.com> <4F5902D9.1080006@bell-labs.com> <4F5904A0.5090709@nostrum.com> In-Reply-To: <4F5904A0.5090709@nostrum.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.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-control-07 section 6.3 algorithm 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, 08 Mar 2012 19:25:40 -0000 On 03/08/2012 01:12 PM, Adam Roach wrote: > Because responses that you're *sending* will *not* contain overload > information that you need to extract. In fact, you'll need to take > action to *put* overload information in them. Well ... if you are *sending* a response, you're acting as a proxy and in fact, will take out oc parameters from a response going upstream. > Responses that you're *receiving* will potentially contain overload > information that you need to extract and store. Right. > Similarly, requests that you're about to *send* are subject to the > overload state of their next hop host, and might be dropped accordingly. Right. > Requests that you've just *received* aren't (although they might be > subject to local rejection, per the behavior in 5.10.2). Right. > Critically, there are four different behaviors that need to be detailed: > inbound request, outbound request, inbound response, and outbound > response. The algorithm in the draft (and the revised one that you > proposed) seem to mash these all together into two cases (request and > response), which are then slightly or radically wrong, depending on > whether they're applied to inbound or outbound messages. So assume that you are a proxy (the most general of the entities doing overload control). And also assume that when you execute while (true) { sip_msg := get_sip_msg() ... } that if this is a request, it has been picked up from the network and put on your processing queue. If it is a response, then it has been picked up from the network and put on your processing queue. From your viewpoint, requests are now destined downstream subject to overload control. Similarly, responses are to be processed to extract overload control information and proxied upstream. With this context, see if things make more sense. - 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 Internet-Drafts@ietf.org Thu Mar 8 11:38:13 2012 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 4438E21E8021; Thu, 8 Mar 2012 11:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, 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 CIov5QDJvbRx; Thu, 8 Mar 2012 11:38:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7595021E801B; Thu, 8 Mar 2012 11:38:12 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120308193812.9152.79409.idtracker@ietfa.amsl.com> Date: Thu, 08 Mar 2012 11:38:12 -0800 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D ACTION:draft-ietf-soc-overload-rate-control-01.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: Thu, 08 Mar 2012 19:38:13 -0000 --NextPart 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 : Session Initiation Protocol (SIP) Rate Control Author(s) : E. Noel, et al Filename : draft-ietf-soc-overload-rate-control Pages : 12 Date : Feb. 16, 2012 The prevalent use of Session Initiation Protocol (SIP) [RFC3261] in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. Already [draft-ietf-soc-overload-control-07] proposes a loss-based solution to remedy known vulnerabilities of the [RFC3261] SIP 503 (service unavailable) overload control mechanism. This document proposes a rate-based control solution to complement the loss-based control defined in [draft-ietf-soc-overload-control-07]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-soc-overload-rate-control Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-soc-overload-rate-control"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-03-08113812.I-D@ietf.org> --NextPart-- From ecnoel@research.att.com Thu Mar 8 11:45:24 2012 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 C90EE21F84E0 for ; Thu, 8 Mar 2012 11:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 1SRgeDiKt4DA for ; Thu, 8 Mar 2012 11:45:24 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id B99A621F84DA for ; Thu, 8 Mar 2012 11:45:23 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 83BE01200F5 for ; Thu, 8 Mar 2012 14:45:23 -0500 (EST) Received: from njfpsrvexg1.research.att.com (njfpsrvexg1.research.att.com [135.207.177.20]) by mail-blue.research.att.com (Postfix) with ESMTP id F23E5EF654 for ; Thu, 8 Mar 2012 14:45:13 -0500 (EST) Received: from concierge.research.att.com (135.207.179.20) by njfpsrvexg1.research.att.com (135.207.177.20) with Microsoft SMTP Server (TLS) id 8.3.245.1; Thu, 8 Mar 2012 14:44:11 -0500 Received: from njfpsrvexg6.research.att.com ([fe80:0000:0000:0000:a8f7:a94a:213.189.254.11]) by concierge.research.att.com ([135.207.24.83]) with mapi; Thu, 8 Mar 2012 14:44:43 -0500 From: "NOEL, ERIC C (ERIC C)" To: "sip-overload@ietf.org" Date: Thu, 8 Mar 2012 14:46:03 -0500 Thread-Topic: draft-ietf-soc-overload-rate-control-01.txt posted Thread-Index: Acz9ZF+ejDKcvE9YR02Ki5tPZSxy2Q== Message-ID: <2F8FB48C17221643AD77FA295756D2A72406223070@njfpsrvexg6.research.att.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_2F8FB48C17221643AD77FA295756D2A72406223070njfpsrvexg6re_" MIME-Version: 1.0 Subject: [sip-overload] draft-ietf-soc-overload-rate-control-01.txt posted 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, 08 Mar 2012 19:45:25 -0000 --_000_2F8FB48C17221643AD77FA295756D2A72406223070njfpsrvexg6re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Just to let you know updated version for draft-ietf-soc-overload-rate-contr= ol-01.txt was just posted. It addresses a problem in the client operation c= aught by Janet Gunn and provides more insights from Phil Williams on server= rate estimation within the context of priority at the server. Document may be found at: A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-soc-overload-rate-control Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ As this is a companion to draft-ietf-soc-overload-control-07, please review= both drafts in parallel. 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 --_000_2F8FB48C17221643AD77FA295756D2A72406223070njfpsrvexg6re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

Just to let you know updated version for draft-ietf-soc-overload-rate-con= trol-01.txt was just posted. It addresses a problem in the client operation= caught by Janet Gunn and provides more insights from Phil Williams on serv= er rate estimation within the context of priority at the server.=

Do= cument may be found at:

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/= draft-ietf-soc-overload-rate-control

Internet-Drafts are also a= vailable by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts= /

As this is a companion to draft-ietf-soc-overload-control-07, pl= ease review both drafts in parallel.

Thanks,

Eric Noel

AT&T Labs= , Inc.
Rethink Possible

Network Design and Performance Analysis
200 Sou= th Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174

ec= noel@att.com

= --_000_2F8FB48C17221643AD77FA295756D2A72406223070njfpsrvexg6re_-- From adam@nostrum.com Thu Mar 8 12:04:17 2012 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 D6B3821F8687 for ; Thu, 8 Mar 2012 12:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, SPF_PASS=-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 NnBF0k-15WYJ for ; Thu, 8 Mar 2012 12:04:17 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 550A021F8678 for ; Thu, 8 Mar 2012 12:04:17 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q28K4E9e020832 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Mar 2012 14:04:14 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4F5910BE.2010505@nostrum.com> Date: Thu, 08 Mar 2012 14:04:14 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <4F57B393.3020702@nostrum.com> <4F58F595.9070107@bell-labs.com> <4F58FACB.2020602@nostrum.com> <4F5902D9.1080006@bell-labs.com> <4F5904A0.5090709@nostrum.com> <4F5908C1.8060709@bell-labs.com> In-Reply-To: <4F5908C1.8060709@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-control-07 section 6.3 algorithm 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, 08 Mar 2012 20:04:18 -0000 On 3/8/12 1:30 PM, Vijay K. Gurbani wrote: > > So assume that you are a proxy (the most general of the entities doing > overload control). And also assume that when you execute > > while (true) { > sip_msg := get_sip_msg() ... } > > that if this is a request, it has been picked up from the network and > put on your processing queue. If it is a response, then it has been > picked up from the network and put on your processing queue. From your > viewpoint, requests are now destined downstream subject to overload > control. Similarly, responses are to be processed to extract overload > control information and proxied upstream. > > With this context, see if things make more sense. No, because there's a lot of processing that needs to take place between receipt of a message and sending that same message. This is complicated by the fact that proxies can, for example, fork requests. I think what we really want here is to show one loop that demonstrates how the entity (proxy or user agent) handles messages that are going to the network. Then, separately, we should show a different loop that handles messages coming from the network. I suspect we're not going to get untangled from the axle otherwise. /a From vkg@bell-labs.com Thu Mar 8 12:22:47 2012 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 5BFB221F8658 for ; Thu, 8 Mar 2012 12:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.946 X-Spam-Level: X-Spam-Status: No, score=-106.946 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 n1Sol6Y65L4z for ; Thu, 8 Mar 2012 12:22:42 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id ED3B121E8036 for ; Thu, 8 Mar 2012 12:22:41 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q28KMc6r018203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Mar 2012 14:22:38 -0600 (CST) 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 q28KMbc8013486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Mar 2012 14:22:37 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q28KMbHC020205; Thu, 8 Mar 2012 14:22:37 -0600 (CST) Message-ID: <4F591621.7040805@bell-labs.com> Date: Thu, 08 Mar 2012 14:27:13 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: Adam Roach References: <4F57B393.3020702@nostrum.com> <4F58F595.9070107@bell-labs.com> <4F58FACB.2020602@nostrum.com> <4F5902D9.1080006@bell-labs.com> <4F5904A0.5090709@nostrum.com> <4F5908C1.8060709@bell-labs.com> <4F5910BE.2010505@nostrum.com> In-Reply-To: <4F5910BE.2010505@nostrum.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.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-control-07 section 6.3 algorithm 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, 08 Mar 2012 20:22:47 -0000 On 03/08/2012 02:04 PM, Adam Roach wrote: > No, because there's a lot of processing that needs to take place > between receipt of a message and sending that same message. Absolutely, however showing all of that processing will simply detract from showcasing the overload control behaviour in an example algorithm. We have to abstract out a lot of information to keep the focus on the overload control part of the algorithm. > This is complicated by the fact that proxies can, for example, fork > requests. Sure, and this can be trivially handled by applying the overload control to each branch, and generating a local response if a particular branch belongs to a server that is under overload, and caching that response until all branches have responded, and then doing response aggregation to choose the best response, etc. But again, we do not have to show all of this in a reference algorithm. Showing all of this processing detracts from the main message of the reference algorithm, which should be to highlight which messages are dropped and how that choice is made. > I think what we really want here is to show one loop that > demonstrates how the entity (proxy or user agent) handles messages > that are going to the network. Then, separately, we should show a > different loop that handles messages coming from the network. Then you straddle the processing between two event loops and folks will have questions on their execution model --- are they executing in the same thread, different threads? I suspect that this will become just as complex as the current reference algorithm is. > I suspect we're not going to get untangled from the axle otherwise. I'd respectfully urge you one more time to see if you can make sense with the context that get_sip_msg() picks up the next SIP message from its processing queue to focus on the overload control part. But if that is still not clear, then I am open to suggestions on how to proceed. I can work with you to break this up into two processing loops and see if they make things more understandable. 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 emcmurry@estacado.net Thu Mar 8 12:32:10 2012 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 AA98621F84D1 for ; Thu, 8 Mar 2012 12:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599] 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 ok4rs9cSmTMT for ; Thu, 8 Mar 2012 12:31:47 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7CB21F84D3 for ; Thu, 8 Mar 2012 12:31:46 -0800 (PST) Received: from embp.mcmurry.home (cpe-76-184-255-34.tx.res.rr.com [76.184.255.34]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q28KVaqm067528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Mar 2012 14:31:41 -0600 (CST) (envelope-from emcmurry@estacado.net) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Eric McMurry In-Reply-To: <4F5910BE.2010505@nostrum.com> Date: Thu, 8 Mar 2012 14:31:31 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F57B393.3020702@nostrum.com> <4F58F595.9070107@bell-labs.com> <4F58FACB.2020602@nostrum.com> <4F5902D9.1080006@bell-labs.com> <4F5904A0.5090709@nostrum.com> <4F5908C1.8060709@bell-labs.com> <4F5910BE.2010505@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1257) Cc: sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-control-07 section 6.3 algorithm 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, 08 Mar 2012 20:32:10 -0000 I agree with this sentiment. I think I (and probably Adam) were coming = from the assumption that the algorithm described in 6.3 was for clients, = based on the start of the section: This section describes a default algorithm that a SIP client can to throttle SIP traffic going downstream by the percentage loss value specified in the "oc" parameter. (btw, there is a grammar issue in the first sentence) taken as a client algorithm, it only made sense to me if it described = the clients *sending* behavior, which is what I was trying to call out = in my first message. As you and Adam have pointed out, there are = different behaviors for different elements in the network. The UAC and = UAS can not necessarily be described with the same algorithm (at least = not clearly). Proxies are another mater also as their behavior is = potentially more complex. So let's consider what the interesting cases are that warrant putting = ink to the algorithm. There are several cases to look at: * sending from an client endpoint * receiving at an client endpoint * receiving at a server endpoint * sending from a server endpoint * receiving from a client endpoint at an intermediary * sending to a client endpoint at an intermediary * receiving from a server endpoint at an intermediary * sending to a server endpoint at an intermediary Since this is only for hop-by-hop, I have not listed all possibilities. = I am also limiting the scope of this discussion to the loss-based = default algorithm, and not including others or anything else such as = algorithm negotiation. Working our way down the list: * sending from an client endpoint The behavior here is more complex than can be described in a couple of = sentences and would be made more clear with an algorithmic description. = The modifications to the algorithm in 6.3 from Adam fit the bill here. * receiving at an client endpoint I think this can be described clearly in natural language. * receiving at a server endpoint I think this can be described clearly in natural language. * sending from a server endpoint I think this can be described clearly in natural language. * receiving from a client endpoint at an intermediary I think this can be described clearly in natural language. * sending to a client endpoint at an intermediary When the intermediary is a proxy, the behavior here is potentially = complex. I think this would be made more clear with an algorithmic = description. * receiving from a server endpoint at an intermediary When the intermediary is a proxy, the behavior here is potentially = complex. I think this would be made more clear with an algorithmic = description. It may make sense to cover this in conjunction with the = algorithm for sending to a client endpoint from a proxy. * sending to a server endpoint at an intermediary I think this can be described clearly in natural language. So, I think a couple of algorithms are in order. The first provided by = the doc along with Adam's modifications, and a second describing proxy = behavior. On Mar 8, 2012, at 14:04 , Adam Roach wrote: > On 3/8/12 1:30 PM, Vijay K. Gurbani wrote: >>=20 >> So assume that you are a proxy (the most general of the entities = doing >> overload control). And also assume that when you execute >>=20 >> while (true) { >> sip_msg :=3D get_sip_msg() ... } >>=20 >> that if this is a request, it has been picked up from the network and >> put on your processing queue. If it is a response, then it has been >> picked up from the network and put on your processing queue. =46rom = your >> viewpoint, requests are now destined downstream subject to overload >> control. Similarly, responses are to be processed to extract = overload >> control information and proxied upstream. >>=20 >> With this context, see if things make more sense. >=20 > No, because there's a lot of processing that needs to take place = between receipt of a message and sending that same message. This is = complicated by the fact that proxies can, for example, fork requests. >=20 > I think what we really want here is to show one loop that demonstrates = how the entity (proxy or user agent) handles messages that are going to = the network. Then, separately, we should show a different loop that = handles messages coming from the network. >=20 > I suspect we're not going to get untangled from the axle otherwise. >=20 > /a > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From vkg@bell-labs.com Thu Mar 8 12:44:06 2012 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 0CB2821E8039 for ; Thu, 8 Mar 2012 12:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.941 X-Spam-Level: X-Spam-Status: No, score=-106.941 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ksugFuqGiMXt for ; Thu, 8 Mar 2012 12:44:05 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 10AEA21E8032 for ; Thu, 8 Mar 2012 12:44:00 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q28KhrYG018582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Mar 2012 14:43:53 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q28Khqe5010020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Mar 2012 14:43:53 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q28Khqoj006822; Thu, 8 Mar 2012 14:43:52 -0600 (CST) Message-ID: <4F591B1C.1080205@bell-labs.com> Date: Thu, 08 Mar 2012 14:48:28 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: Eric McMurry References: <4F57B393.3020702@nostrum.com> <4F58F595.9070107@bell-labs.com> <4F58FACB.2020602@nostrum.com> <4F5902D9.1080006@bell-labs.com> <4F5904A0.5090709@nostrum.com> <4F5908C1.8060709@bell-labs.com> <4F5910BE.2010505@nostrum.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.12 Cc: sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-control-07 section 6.3 algorithm 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, 08 Mar 2012 20:44:06 -0000 On 03/08/2012 02:31 PM, Eric McMurry wrote: > I agree with this sentiment. I think I (and probably Adam) were > coming from the assumption that the algorithm described in 6.3 was > for clients, based on the start of the section: > > This section describes a default algorithm that a SIP client can to > throttle SIP traffic going downstream by the percentage loss value > specified in the "oc" parameter. Eric: Understood. However, because SIP is so rich, a SIP client could be part of the proxy as well. When I was doing work in the sipclf specification, I was told to simply call it a SIP client instead of "the SIP client part of a proxy..." Of course, I can make it clear in the overload draft that wherever "SIP client" is mentioned, it could mean a SIP UAC or proxy. [...] > So, I think a couple of algorithms are in order. The first provided > by the doc along with Adam's modifications, and a second describing > proxy behavior. My contention is that the algorithm in the document and the one I modified based on your and Adam's input is the most general algorithm; i.e., one corresponding to the proxy processing (I can add more background text saying that get_sip_msg() gets a SIP message from the proxy's processing queue, etc.) If we do a decent job at specifying the most complex of the algorithms, implementers will know what to do for the simpler cases. Now the question is, did we (or I) do a decent job of specifying the most complex of the algorithms? I think I did, but it is clear that there is still some work to be done. I fear that providing multiple algorithms or descriptions will simply create more questions and problems. The focus should be on the overload control behaviour vis-a-vis percentage of messages to drop and what to do when there aren't enough of category 1 messages, etc. The redone algorithm I posted that includes your and Adam's comments improves on the one in the document, I believe. But clearly, we all have to consent that it is good enough so we can get the work finished. 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 adam@nostrum.com Thu Mar 8 13:29:07 2012 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 3499D21F8550 for ; Thu, 8 Mar 2012 13:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, SPF_PASS=-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 cn0HnLcZR9EQ for ; Thu, 8 Mar 2012 13:29:01 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id DDDD721F853D for ; Thu, 8 Mar 2012 13:28:56 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q28LSq41034150 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Mar 2012 15:28:52 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4F592494.2030207@nostrum.com> Date: Thu, 08 Mar 2012 15:28:52 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <4F57B393.3020702@nostrum.com> <4F58F595.9070107@bell-labs.com> <4F58FACB.2020602@nostrum.com> <4F5902D9.1080006@bell-labs.com> <4F5904A0.5090709@nostrum.com> <4F5908C1.8060709@bell-labs.com> <4F5910BE.2010505@nostrum.com> <4F591621.7040805@bell-labs.com> In-Reply-To: <4F591621.7040805@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-control-07 section 6.3 algorithm 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, 08 Mar 2012 21:29:07 -0000 On 3/8/12 2:27 PM, Vijay K. Gurbani wrote: > I'd respectfully urge you one more time to see if you can make sense > with the context that get_sip_msg() picks up the next SIP message from > its processing queue to focus on the overload control part. But if > that is still not clear, then I am open to suggestions on how to > proceed. I can work with you to break this up into two processing > loops and see if they make things more understandable. If you're really concerned about the concurrency implications of showing this as two different loops, I'm okay collapsing it into a single loop servicing a work queue. But we really need to be clear about where the messages are coming from. I think you really do want to show something that works for both user agents and for proxies. I don't think most implementors will be able to adapt what you have right now into something applicable to user agents. On the other hand, if you split things up to handle message receipt separately from message sending, then use in a user agent context becomes much clearer. What's nice about doing it that way is that it allows you to completely ignore the complexities of proxy message handling (e.g. forking) by hiding them behind the "process_msg" function. So, here's what I propose. It's based heavily on your most recent code, but it handles inbound and outbound messages separately and explains where the SIP messages are coming from: cat1 := 80.0 // Category 1 --- subject to reduction cat2 := 100.0 - cat1 // Category 2 --- Not subject to reduction // 80/20 mix. while (true) { // We're modeling message processing as a single work queue // that contains both incoming and outgoing messages. sip_msg := get_next_message_from_work_queue() switch (sip_msg.type) { case outbound request: destination := get_next_hop(sip_msg) oc_context := get_oc_context(destination) if (oc_context == null) { send_to_network(sip_msg) // Process it normally by sending the // request to the next hop since this particular destination // is not subject to overload } else { // Determine if server wants to enter in overload or is in // overload in_oc := extract_in_oc(oc_context) oc_value := extract_oc(oc_context) oc_validity := extract_oc_validity(oc_context) if (in_oc == false or oc_validity is not in effect) { send_to_network(sip_msg) // Process it normally by sending the // request to the next hop since this particular destination // is not subject to overload. Optionally, clear // the oc context for this server (not shown). } else { category := assign_msg_to_category(sip_msg) drop_msg := false pct_to_reduce := min(100, oc_value / cat1 * 100) r := random() if (r <= pct_to_reduce) { drop_msg := true } if (category == cat2 && drop_msg == true) { if (local_policy(sip_msg, oc_value) says process message) { drop_msg := 0 // See Note 1 below } } if (drop_msg == false) { send_to_network(sip_msg) // Process it normally by sending // the request to the next hop } else { // Do not send request downstream, handle locally by // generating response (if a proxy) or treating as // an error (if a user agent). } } } end case // outbound request case outbound response: if (we are in overload) { add_overload_parameters(sip_msg) } send_to_network(sip_msg) end case // outbound response case inbound response: if (sip_msg has oc parameter values) { create_or_update_oc_context() // For the specific server // that sent the response, create or update the oc context; // i.e., extract the values of the oc-related parameters // and store them for later use. } process_msg(sip_msg) end case // inbound response case inbound request: if (sip_msg does not have oc parameter values && we are in overload) { r := random() if (r <= our overload metric that we're advertising) { send_response(sip_msg, 503) } else { process_msg(sip_msg) } } end case // inbound request } } I have at least one other major issue I think needs to be fixed, but I don't want to throw it into the mix until we have preliminary agreement on how we break up the processing. /a From jgunn6@csc.com Thu Mar 8 13:42:02 2012 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 A8A2321E8036; Thu, 8 Mar 2012 13:42:02 -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 Vf8tFy359yE9; Thu, 8 Mar 2012 13:42:01 -0800 (PST) Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by ietfa.amsl.com (Postfix) with ESMTP id 9B93E21E802D; Thu, 8 Mar 2012 13:41:58 -0800 (PST) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-15.tower-171.messagelabs.com!1331242916!1153565!1 X-Originating-IP: [20.137.2.87] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23127 invoked from network); 8 Mar 2012 21:41:57 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-15.tower-171.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Mar 2012 21:41:57 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q28Lfslo008599; Thu, 8 Mar 2012 16:41:55 -0500 In-Reply-To: <2F8FB48C17221643AD77FA295756D2A72406223070@njfpsrvexg6.research.att.com> References: <2F8FB48C17221643AD77FA295756D2A72406223070@njfpsrvexg6.research.att.com> To: "NOEL, ERIC C (ERIC C)" MIME-Version: 1.0 X-KeepSent: ACDAA28F:20BCF797-852579BB:0076F904; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP3 July 11, 2011 From: Janet P Gunn Message-ID: Date: Thu, 8 Mar 2012 16:41:53 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 03/08/2012 04:38:55 PM, Serialize complete at 03/08/2012 04:38:55 PM Content-Type: multipart/alternative; boundary="=_alternative 007733AC852579BB_=" Cc: sip-overload-bounces@ietf.org, "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-01.txt posted 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, 08 Mar 2012 21:42:02 -0000 This is a multipart message in MIME format. --=_alternative 007733AC852579BB_= Content-Type: text/plain; charset="US-ASCII" That link didn't work for me. Try this one http://www.ietf.org/id/draft-ietf-soc-overload-rate-control-01.txt or https://datatracker.ietf.org/doc/draft-ietf-soc-overload-rate-control/ Janet From: "NOEL, ERIC C (ERIC C)" To: "sip-overload@ietf.org" Date: 03/08/2012 02:45 PM Subject: [sip-overload] draft-ietf-soc-overload-rate-control-01.txt posted Sent by: sip-overload-bounces@ietf.org Folks, Just to let you know updated version for draft-ietf-soc-overload-rate-control-01.txt was just posted. It addresses a problem in the client operation caught by Janet Gunn and provides more insights from Phil Williams on server rate estimation within the context of priority at the server. Document may be found at: A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-soc-overload-rate-control Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ As this is a companion to draft-ietf-soc-overload-control-07, please review both drafts in parallel. 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 _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload --=_alternative 007733AC852579BB_= Content-Type: text/html; charset="US-ASCII" That link didn't work for me.

Try this one

http://www.ietf.org/id/draft-ietf-soc-overload-rate-control-01.txt
or
https://datatracker.ietf.org/doc/draft-ietf-soc-overload-rate-control/

Janet

From: "NOEL, ERIC C (ERIC C)" <ecnoel@research.att.com>
To: "sip-overload@ietf.org" <sip-overload@ietf.org>
Date: 03/08/2012 02:45 PM
Subject: [sip-overload] draft-ietf-soc-overload-rate-control-01.txt posted
Sent by: sip-overload-bounces@ietf.org

Folks,

Just to let you know updated version for draft-ietf-soc-overload-rate-control-01.txt was just posted. It addresses a problem in the client operation caught by Janet Gunn and provides more insights from Phil Williams on server rate estimation within the context of priority at the server.

Document may be found at:

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-soc-overload-rate-control

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

As this is a companion to draft-ietf-soc-overload-control-07, please review both drafts in parallel.

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
_______________________________________________ sip-overload mailing list sip-overload@ietf.orghttps://www.ietf.org/mailman/listinfo/sip-overload
--=_alternative 007733AC852579BB_=-- From vkg@bell-labs.com Fri Mar 9 11:35:31 2012 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 8084721F863F for ; Fri, 9 Mar 2012 11:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.935 X-Spam-Level: X-Spam-Status: No, score=-106.935 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 6OpvQ5Pp1FzV for ; Fri, 9 Mar 2012 11:35:30 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 878D621F8617 for ; Fri, 9 Mar 2012 11:35:30 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q29JZTA1017991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Mar 2012 13:35:29 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q29JZTG1017941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Mar 2012 13:35:29 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q29JZSRJ008926; Fri, 9 Mar 2012 13:35:29 -0600 (CST) Message-ID: <4F5A5C95.1060905@bell-labs.com> Date: Fri, 09 Mar 2012 13:40:05 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: Adam Roach References: <4F57B393.3020702@nostrum.com> <4F58F595.9070107@bell-labs.com> <4F58FACB.2020602@nostrum.com> <4F5902D9.1080006@bell-labs.com> <4F5904A0.5090709@nostrum.com> <4F5908C1.8060709@bell-labs.com> <4F5910BE.2010505@nostrum.com> <4F591621.7040805@bell-labs.com> <4F592494.2030207@nostrum.com> In-Reply-To: <4F592494.2030207@nostrum.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.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-control-07 section 6.3 algorithm 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, 09 Mar 2012 19:35:31 -0000 On 03/08/2012 03:28 PM, Adam Roach wrote: > So, here's what I propose. It's based heavily on your most recent code, > but it handles inbound and outbound messages separately and explains > where the SIP messages are coming from: [...] Adam: Sorry for the delay, was tied up in meetings. I went through your proposal of breaking the processing down. I am fine with it, however, I think there are some nuances in the "case inbound request" that we need to be more intelligent about. I think something along the following lines should be specified for that case: ... case inbound request: if (we are not in overload) { process_msg(sip_msg) } else { // We are in overload if (sip_msg has oc parameters) { // Upstream client supports oc process_msg(sip_msg) // and only sends important requests } else { // Upstream client does not support oc if (local_policy(sip_msg) says process message) { process_msg(sip_msg) } else { send_response(sip_msg, 503) } } } Here, if the above code is being executed by an overloaded proxy and the upstream client does not support overload, then the proxy has to consult local policy on what to do. If local policy says process the request, then the request gets added to the work queue and re-appears back in the event loop and is handled by the "case outbound request" part of the code. If the above code is being executed by a terminal UAS under the same conditions (i.e., UAS is overloaded and the upstream client does not support overload), then local policy can decide whether to accept that request or send a 503. Thoughts? 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 adam@nostrum.com Fri Mar 9 12:10:48 2012 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 12D0521F86DF for ; Fri, 9 Mar 2012 12:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, SPF_PASS=-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 QduBoNTia-08 for ; Fri, 9 Mar 2012 12:10:47 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 15FF821F86A6 for ; Fri, 9 Mar 2012 12:10:46 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q29KAiTT058827 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 9 Mar 2012 14:10:45 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4F5A63C4.5040600@nostrum.com> Date: Fri, 09 Mar 2012 14:10:44 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <4F57B393.3020702@nostrum.com> <4F58F595.9070107@bell-labs.com> <4F58FACB.2020602@nostrum.com> <4F5902D9.1080006@bell-labs.com> <4F5904A0.5090709@nostrum.com> <4F5908C1.8060709@bell-labs.com> <4F5910BE.2010505@nostrum.com> <4F591621.7040805@bell-labs.com> <4F592494.2030207@nostrum.com> <4F5A5C95.1060905@bell-labs.com> In-Reply-To: <4F5A5C95.1060905@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-control-07 section 6.3 algorithm 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, 09 Mar 2012 20:10:48 -0000 On 3/9/12 1:40 PM, Vijay K. Gurbani wrote: > On 03/08/2012 03:28 PM, Adam Roach wrote: >> So, here's what I propose. It's based heavily on your most recent code, >> but it handles inbound and outbound messages separately and explains >> where the SIP messages are coming from: [...] > > Adam: Sorry for the delay, was tied up in meetings. > > I went through your proposal of breaking the processing down. > I am fine with it, however, I think there are some nuances in the > "case inbound request" that we need to be more intelligent about. > > I think something along the following lines should be specified for > that case: > > ... > case inbound request: > > if (we are not in overload) { > process_msg(sip_msg) > } > else { // We are in overload > if (sip_msg has oc parameters) { // Upstream client supports oc > process_msg(sip_msg) // and only sends important requests > } > else { // Upstream client does not support oc > if (local_policy(sip_msg) says process message) { > process_msg(sip_msg) > } > else { > send_response(sip_msg, 503) > } > } > } > > Here, if the above code is being executed by an overloaded > proxy and the upstream client does not support overload, then the > proxy has to consult local policy on what to do. If local policy > says process the request, then the request gets added to the work > queue and re-appears back in the event loop and is handled by the > "case outbound request" part of the code. > > If the above code is being executed by a terminal UAS under the same > conditions (i.e., UAS is overloaded and the upstream client does > not support overload), then local policy can decide whether to > accept that request or send a 503. > > Thoughts? That sounds good to me. /a From vkg@bell-labs.com Fri Mar 9 12:16:11 2012 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 E9C5521E809B for ; Fri, 9 Mar 2012 12:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.956 X-Spam-Level: X-Spam-Status: No, score=-106.956 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 N6EycduMGu1o for ; Fri, 9 Mar 2012 12:16:11 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 339F221E809A for ; Fri, 9 Mar 2012 12:16:11 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q29KGAs4000734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Mar 2012 14:16:10 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q29KG9WP009529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Mar 2012 14:16:09 -0600 Received: from shoonya.ih.lucent.com (shoonya-135185238235.ih.lucent.com [135.185.238.235] (may be forged)) by umail.lucent.com (8.13.8/TPES) with ESMTP id q29KG8QQ004196; Fri, 9 Mar 2012 14:16:09 -0600 (CST) Message-ID: <4F5A661B.1040509@bell-labs.com> Date: Fri, 09 Mar 2012 14:20:43 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: Adam Roach References: <4F57B393.3020702@nostrum.com> <4F58F595.9070107@bell-labs.com> <4F58FACB.2020602@nostrum.com> <4F5902D9.1080006@bell-labs.com> <4F5904A0.5090709@nostrum.com> <4F5908C1.8060709@bell-labs.com> <4F5910BE.2010505@nostrum.com> <4F591621.7040805@bell-labs.com> <4F592494.2030207@nostrum.com> <4F5A5C95.1060905@bell-labs.com> <4F5A63C4.5040600@nostrum.com> In-Reply-To: <4F5A63C4.5040600@nostrum.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.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-control-07 section 6.3 algorithm 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, 09 Mar 2012 20:16:12 -0000 On 03/09/2012 02:10 PM, Adam Roach wrote: > That sounds good to me. Adam: OK, thanks. So, I can release a new revision with the updated algorithm (we still have Monday left to submit). I will do so unless I hear otherwise before Monday. Thank you (and Eric) for helping flesh out the algorithm with the various cases. - 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 ibc@aliax.net Sat Mar 10 06:40:39 2012 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 2391121F85D6 for ; Sat, 10 Mar 2012 06:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 g-brixUQIuvM for ; Sat, 10 Mar 2012 06:40:38 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8965521F85AC for ; Sat, 10 Mar 2012 06:40:38 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so2914446vcb.31 for ; Sat, 10 Mar 2012 06:40:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding:x-gm-message-state; bh=SSON5VE/GmJgF2y1tuUi/nVlVaJXg1SlHCeFaxqrlVk=; b=pHCBIlBXSwRpv+x08xRFPN0RLlG9r7rTbE3eHlrUeMPpNsWqY4O6qKXS4EMOvwVQ1q b8YDD+k1QciMSdJt563qduyG9W5qc7SICdGhlXbOldV833hQSPnER+aSlDI/Sx57/Vv9 x55AQ3nlNSANknRiBCkBJklmSqbL0c/tbKnlE4PLfd+RY1lMSzgcjlhqWNTVqqeQMR8v rbUez+o1BWGdXc0xv8nC8xFASSQYyGvZDci+YZ9FCQUo9+0XTq9jLnE2axRk7GKkih9x MDoAaq5Hy85mOLVgRdl0XGeMPh2axzr7aCxX0yLuwwM2HRcbTkGz4wMMIr4qwNYsfkL+ WDJg== Received: by 10.52.180.98 with SMTP id dn2mr9485104vdc.61.1331390438083; Sat, 10 Mar 2012 06:40:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.99.131 with HTTP; Sat, 10 Mar 2012 06:40:18 -0800 (PST) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 10 Mar 2012 15:40:18 +0100 Message-ID: To: sip-overload@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkhc7KDNVKsgP4Z4VHwW3LHI++2pAywOVO6OnfxlqB/7yFuOE5ezsKq0emHHOs/BGbsOQM9 Subject: [sip-overload] draft-ietf-soc-overload-control-07 - Too much "MUST"? 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: Sat, 10 Mar 2012 14:40:39 -0000 Hi, as an initial reading of the draft (revision 07) I've found various cases in which the text says things like: ------------------------------- 4.1. The oc parameter This parameter is inserted by the SIP client and updated by the SIP server. A SIP client MUST add an "oc" parameter to the topmost Via [...] The downstream server MUST add a value to the "oc" parameter in the response going upstream. ------------------------------- Reading that it seems that any SIP client and any SIP server/proxy should implement this specification. I would suggest a "Terminology" section in which is stated that this document describes a "SIP client" as a SIP entity which implements this specification and wants to use it, and "SIP server" as a SIP proxy or server that implements this specification and, as well, wants to use it. There is no "Require/Supported" negotiation mechanism here since information is just added as Via parameters, so IMHO the document should relax those "MUST" or clearly explain the scope of them. --=20 I=C3=B1aki Baz Castillo From jgunn6@csc.com Sat Mar 10 08:31:23 2012 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 D700021F8666; Sat, 10 Mar 2012 08:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 YIqJNKpvMSPd; Sat, 10 Mar 2012 08:31:23 -0800 (PST) Received: from mail170.messagelabs.com (mail170.messagelabs.com [216.82.253.227]) by ietfa.amsl.com (Postfix) with ESMTP id C57C021F8667; Sat, 10 Mar 2012 08:31:22 -0800 (PST) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-16.tower-170.messagelabs.com!1331397080!2596087!1 X-Originating-IP: [20.137.2.87] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2986 invoked from network); 10 Mar 2012 16:31:21 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-16.tower-170.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Mar 2012 16:31:21 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2AGVJha003982; Sat, 10 Mar 2012 11:31:20 -0500 In-Reply-To: References: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= MIME-Version: 1.0 X-KeepSent: 1F28F0B4:238DD4A8-852579BD:005A9170; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP3 July 11, 2011 From: Janet P Gunn Message-ID: Date: Sat, 10 Mar 2012 11:31:10 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 03/10/2012 11:28:24 AM, Serialize complete at 03/10/2012 11:28:24 AM Content-Type: multipart/alternative; boundary="=_alternative 005AC192852579BD_=" Cc: sip-overload-bounces@ietf.org, sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-control-07 - Too much "MUST"? 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: Sat, 10 Mar 2012 16:31:24 -0000 This is a multipart message in MIME format. --=_alternative 005AC192852579BD_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable See section 2 " Unless otherwise specified, all SIP entities described in this document are assumed to support this specification. The normative statements in this specification as they apply to SIP clients and SIP servers assume that both the SIP clients and SIP servers support this specification. If, for instance, only a SIP client supports this specification and not the SIP server, then follows that the normative statements in this specification pertinent to the behavior of a SIP server do not apply to the server that does not support this specification." Janet From: I=F1aki Baz Castillo To: sip-overload@ietf.org Date: 03/10/2012 09:40 AM Subject: [sip-overload] draft-ietf-soc-overload-control-07 - Too=20 much "MUST"? Sent by: sip-overload-bounces@ietf.org Hi, as an initial reading of the draft (revision 07) I've found various cases in which the text says things like: ------------------------------- 4.1. The oc parameter This parameter is inserted by the SIP client and updated by the SIP server. A SIP client MUST add an "oc" parameter to the topmost Via [...] The downstream server MUST add a value to the "oc" parameter in the response going upstream. ------------------------------- Reading that it seems that any SIP client and any SIP server/proxy should implement this specification. I would suggest a "Terminology" section in which is stated that this document describes a "SIP client" as a SIP entity which implements this specification and wants to use it, and "SIP server" as a SIP proxy or server that implements this specification and, as well, wants to use it. There is no "Require/Supported" negotiation mechanism here since information is just added as Via parameters, so IMHO the document should relax those "MUST" or clearly explain the scope of them. --=20 I=F1aki Baz Castillo =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload --=_alternative 005AC192852579BD_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

See section 2

" Unless otherwise specified, all SIP entities described in this
document are assumed to support this specification.

The normative statemen= ts in this specification as they apply to SIP
clients and SIP servers assume that both the SIP clients and SIP
servers support this s= pecification. If, for instance, only a SIP
client supports this s= pecification and not the SIP server, then
follows that the norma= tive statements in this specification pertinent
to the behavior of a S= IP server do not apply to the server that does
not support this speci= fication."

Janet

From: = I=F1aki Baz Castillo <ibc@aliax.net>
To: &n= bsp; sip-overload@ietf.org
Date: = 03/10/2012 09:40 AM
Subject: &nbs= p; [sip-overload] draft-ietf-soc-overload-control-07 - Too much "MUST"?
Sent by: &nbs= p; sip-overload-bounces= @ietf.org

Hi, as an initial reading of the draft (revision 07) I've found various cases in which the text says things like: ------------------------------- 4.1. The oc parameter This parameter is inserted by the SIP client and updated by the SIP server. A SIP client MUST add an "oc" parameter to the topmost Via [...] The downstream server MUST add a value to the "oc" parame= ter in the response going upstream. ------------------------------- Reading that it seems that any SIP client and any SIP server/proxy should implement this specification. I would suggest a "Terminology&qu= ot; section in which is stated that this document describes a "SIP client&= quot; as a SIP entity which implements this specification and wants to use it, and "SIP server" as a SIP proxy or server that implements this specification and, as well, wants to use it. There is no "Require/Supported" negotiation mechanism here since<= br> information is just added as Via parameters, so IMHO the document should relax those "MUST" or clearly explain the scope of them. -- I=F1aki Baz Castillo <ibc@aliax.net> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F sip-overload mailing list sip-overload@ietf.org= https://www.ietf.org/mailman/listinfo/sip-overload
--=_alternative 005AC192852579BD_=-- From ibc@aliax.net Sun Mar 11 08:56:38 2012 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 3346821F86F8 for ; Sun, 11 Mar 2012 08:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_COULD=0.917] 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 vO1EjdxlBQ-C for ; Sun, 11 Mar 2012 08:56:37 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A6D2821F86C2 for ; Sun, 11 Mar 2012 08:56:37 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so3857671vcb.31 for ; Sun, 11 Mar 2012 08:56:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=FAYoh31dq/ZpNk0m3Z8r4S/RGd5vGquE0m6r7ROPHig=; b=ACdxjdFFvH1HyOlmrpcnNyqvbwMSWakDg+IoRrnD9mz02cMlcqXUjAlyYhm7s5+rsZ mDC2J3GVUtzzDftDetcIWzQZHTtUbg2sdsNCiIOEuDPgzOu6taDb+wux2x/0N27LVfsr Mn8j8Q0rG52rV3Djkhd1YTFpfW5ktJpafAXh6eduw98rW7nO2Tj7UO0dGD19TTmqc/ig mKfE0HvsIJ0Iug3RJIxGRXISfPTHfEMopo2yKLyO+udSWpXxvUGLAhvi8HtwDsodM36K +54osaqdSRIIOOWHwLJJIGRwYrl2BLj0Xa2xvkL8/oWd81+Yj5160e432JpAG4zBhVbM m81w== Received: by 10.52.22.46 with SMTP id a14mr12547213vdf.27.1331481397065; Sun, 11 Mar 2012 08:56:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.99.131 with HTTP; Sun, 11 Mar 2012 08:56:17 -0700 (PDT) In-Reply-To: References:

From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 11 Mar 2012 16:56:17 +0100 Message-ID: To: Janet P Gunn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlP0Hv0IotC/i9ADaGyxexBr5BJE8dRcAuxN4PG2z4Sy1hATfHIMlYZusGxYTBqot1KGWlz Cc: sip-overload-bounces@ietf.org, sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-control-07 - Too much "MUST"? 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: Sun, 11 Mar 2012 15:56:38 -0000 2012/3/10 Janet P Gunn : > See section 2 > > " =C2=A0 Unless otherwise specified, all SIP entities described in this > =C2=A0 =C2=A0document are assumed to support this specification. > > =C2=A0 =C2=A0The normative statements in this specification as they apply= to SIP > =C2=A0 =C2=A0clients and SIP servers assume that both the SIP clients and= SIP > =C2=A0 =C2=A0servers support this specification. =C2=A0If, for instance, = only a SIP > =C2=A0 =C2=A0client supports this specification and not the SIP server, t= hen > =C2=A0 =C2=A0follows that the normative statements in this specification = pertinent > =C2=A0 =C2=A0to the behavior of a SIP server do not apply to the server t= hat does > =C2=A0 =C2=A0not support this specification." Ok, but maybe section 2 should describe a bit what "SIP client" and "SIP server" means. A "SIP client" implementing overload control could be a SIP proxy or a SIP UAC (B2BUA or whatever), and a "SIP server" coould be a SIP proxy or a SIP UAS (B2BUA, gateway...). Regards. --=20 I=C3=B1aki Baz Castillo From vkg@bell-labs.com Mon Mar 12 07:44:28 2012 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 2788121E8035 for ; Mon, 12 Mar 2012 07:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.487 X-Spam-Level: X-Spam-Status: No, score=-108.487 tagged_above=-999 required=5 tests=[AWL=1.196, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_COULD=0.917, 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 X-BJk8uYonjX for ; Mon, 12 Mar 2012 07:44:24 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id A26CF21E8040 for ; Mon, 12 Mar 2012 07:44:22 -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 q2CEiLjA015134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 12 Mar 2012 09:44:21 -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 q2CEiLNE006440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 12 Mar 2012 09:44:21 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2CEiLnX022877 for ; Mon, 12 Mar 2012 09:44:21 -0500 (CDT) Message-ID: <4F5E0CD7.2030703@bell-labs.com> Date: Mon, 12 Mar 2012 09:48:55 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: sip-overload@ietf.org References:

In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [sip-overload] draft-ietf-soc-overload-control-07 - Too much "MUST"? 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, 12 Mar 2012 14:44:28 -0000 On 03/11/2012 10:56 AM, Iñaki Baz Castillo wrote: > Ok, but maybe section 2 should describe a bit what "SIP client" and > "SIP server" means. A "SIP client" implementing overload control could > be a SIP proxy or a SIP UAC (B2BUA or whatever), and a "SIP server" > coould be a SIP proxy or a SIP UAS (B2BUA, gateway...). Inaki: Thanks for your feedback. Based on your and Janet's conversation, I propose to add the following in Section 2: Note that the terms "SIP client" and "SIP server" are used in their generic forms. Thus, a "SIP client" could refer to the client transaction state machine in a SIP proxy or it could refer to a user agent client. Similarly, a "SIP server" could be a user agent server or the server transaction state machine in a proxy. Various permutations of this are also possible, for instance, SIP clients and servers could also be part of back-to-back user agents (B2BUAs) or gateways. However, irrespective of the context (i.e., proxy, B2BUA, UAS, UAC), "SIP client" applies to any SIP entity that provides overload control to traffic destined downstream. Similarly, "SIP server" applies to any SIP entity that is experiencing overload and would like its upstream neighbour to throttle incoming traffic. Hope that helps. 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 ibc@aliax.net Mon Mar 12 07:53:05 2012 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 5EBC621E8051 for