From rjsparks@nostrum.com Fri Mar 4 13:29:51 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A69E3A6A43 for ; Fri, 4 Mar 2011 13:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24+axP-CFzRp for ; Fri, 4 Mar 2011 13:29:49 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id EB2443A6A2D for ; Fri, 4 Mar 2011 13:29:48 -0800 (PST) Received: from [192.168.2.105] (pool-173-57-105-99.dllstx.fios.verizon.net [173.57.105.99]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p24LUvMk095579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 4 Mar 2011 15:30:57 -0600 (CST) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Mar 2011 15:30:56 -0600 Message-Id: <5DF92544-C0B5-4EF4-82F6-AB789A3CD251@nostrum.com> To: sip-overload@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 173.57.105.99 is authenticated by a trusted mechanism) Subject: [sip-overload] AD review: draft-ietf-soc-overload-design-04 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 21:29:51 -0000 There are a few things to address before moving this document into IETF = LC. 1) "This document is a product of the SIP overload control design team." = should be adjusted to reflect its genesis in the design team and production in the = working group. 2) The document has several passages that are telephony centric - = speaking of=20 failed calls, call attempts, and having the mechanism reject calls. This = language should be generalized - the intended mechanism applies to all uses of = SIP. 3) I don't think the distinction the last paragraph of 5.2 tries to draw = is constructed correctly. The TCP packets between two routers are analogous = to the individual SIP messages between the SIP servers you describe - the routers will see = many TCP packets with different source and destination addresses. The whole = point is that congenstion is managed by the behavior of the endpoints in a given = stream. A direct comparison would be against mechanisms that only affected the behaviors = of a=20 particular pair of SIP endpoints - not changing the behavior of the SIP = servers at all. Please adjust or remove this paragraph. 4) The end of section 6 talks about asking UAs to wait using = 503/retry-after. What 503/retry-after does is ask the next upstream element to wait. I think = it's the intention to scope this discussion to the case where the UA _is_ the next upstream = element, but that needs to be made even more clear. The section should also discuss how an = element knows that the next upstream element is a UA and not another proxy. 5) It would help to clarify in Section 9.1 (particularly paragraph 2) = that "next request" is "the start of another transaction", and not "retransmissions in any = ongoing transaction". 6) In section 9.3, I disagree that 100 Trying does not provide = confirmation of receipt of a message. That is _exactly_ what 100 Trying does, and its point is = to affect the transaction state machine's reliability mechanisms. It means it has been = accepted for processing - this hop is taking responsibility for it now. If you have = an implementation=20 that would cause transaction reliability to fail by sending a 100 early = in the processing as you suggest, that implementation in not conformant to the = specification. Are you instead trying to say that the 100 Trying does not indicate that the = message has=20 already been forwarded? 7) Did you mean dialog instead of session in the first paragraph of = section 12? Surely we have actual research backing up the claim "As a general rule". Can we = point to that please? 8) The security consideration section should note what key security = properties each of the possible models have and what influence that could have on = the mechanism chosen, particularly when specific mechanics have been discussed in a = model's section. For instance, the mechanism detailed in the 4th paragraph of 9.1 is = exposed if an attacker can easily make a new server appear to appear (by sending one message = perhaps), cutting traffic at legitimate servers down by 1/n with each new malicious = appearance. Nits: Section 2 Paragraph 1 Sentence 1: s/to the SIP congestion collapse/to = SIP congestion collapse/ Section 2 Paragraph 3:=20 - s/spend/spent/g. Suggest changing this sentence to "Discarding a SIP=20= message after spending the resources to parse it is expensive."=20 - s/less and less/fewer/, s/more and more/more/ - s/slope/rate/ Section 6 Paragraph 5: s/determine much traffic/determine how much = traffic/ From carlberg@g11.org.uk Mon Mar 7 05:52:00 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C3613A6962 for ; Mon, 7 Mar 2011 05:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEeaWEz-lMZE for ; Mon, 7 Mar 2011 05:51:59 -0800 (PST) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 696FD3A6967 for ; Mon, 7 Mar 2011 05:51:59 -0800 (PST) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:56709 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1Pwarv-0003u6-1t; Mon, 07 Mar 2011 13:53:03 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: ken carlberg Date: Mon, 7 Mar 2011 08:53:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: To: sip-overload@ietf.org X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Subject: [sip-overload] draft-ietf-soc-overload-design-04 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 13:52:00 -0000 hi, I believe some more text is needed for clarification concerning section = 12 (Message Prioritization) of the draft. With respect to the last = sentence of the following: Overload control can require a SIP server to prioritize requests and select requests to be rejected or redirected. The selection is largely a matter of local policy of the SIP server, the overall network, and the services it provides. As a general rule, SIP server should prioritize requests for ongoing sessions over requests that set up a new session. does this statement only apply to priorities of the same level? What if = the priority in setting up a new session is higher than the existing = one? I know of systems that insist on taking a preemptive action, and = others that will never allow this. In this document, I don't believe = one doesn't have to state the action to be taken, but I think it would = help to recognize the potential options at hand. The second paragraph of Section 12 states the following: While there are many factors which can affect the prioritization of SIP requests, the Resource-Priority header field [RFC4412] is a prime candidate for marking the prioritization of SIP requests. Depending on the particular network and the services it offers, a particular namespace and priority value in the RPH it could indicate i) a high priority request, which should be preserved if possible during overload, ii) a low priority request, which should be dropped during overload, or iii) a label, which has no impact on message prioritization in this network. The immediate thought that comes to mind is how do these three options = relate to the existing Namespace/Value tuples that have already been = defined in rfc-4412? Also, at the last wg meeting, I believe someone = asked if a new Namespace/Value should be defined for the overload = condition. Perhaps a statement should be added to the text that covers = this possibility and/or recommendation. -ken From volker.hilt@alcatel-lucent.com Thu Mar 10 18:41:00 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519A73A6840 for ; Thu, 10 Mar 2011 18:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pu613xf-Z20q for ; Thu, 10 Mar 2011 18:40:59 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 33F123A6844 for ; Thu, 10 Mar 2011 18:40:59 -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 p2B2g3b8022894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 10 Mar 2011 20:42:16 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2B2Wp4D013412 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 10 Mar 2011 20:32:51 -0600 Received: from [135.244.41.194] (135.3.63.242) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 10 Mar 2011 20:32:51 -0600 Message-ID: <4D7989CC.7070905@alcatel-lucent.com> Date: Thu, 10 Mar 2011 21:32:44 -0500 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: References: <5DF92544-C0B5-4EF4-82F6-AB789A3CD251@nostrum.com> In-Reply-To: <5DF92544-C0B5-4EF4-82F6-AB789A3CD251@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 Subject: Re: [sip-overload] AD review: draft-ietf-soc-overload-design-04 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 02:41:00 -0000 Robert, thanks for the detailed review. More inline. On 3/4/2011 4:30 PM, Robert Sparks wrote: > There are a few things to address before moving this document into IETF LC. > > 1) "This document is a product of the SIP overload control design team." should be > adjusted to reflect its genesis in the design team and production in the working > group. > Done. > 2) The document has several passages that are telephony centric - speaking of > failed calls, call attempts, and having the mechanism reject calls. This language > should be generalized - the intended mechanism applies to all uses of SIP. > Done. > 3) I don't think the distinction the last paragraph of 5.2 tries to draw is > constructed correctly. The TCP packets between two routers are analogous to the individual > SIP messages between the SIP servers you describe - the routers will see many > TCP packets with different source and destination addresses.The whole point is that > congenstion is managed by the behavior of the endpoints in a given stream. A direct > comparison would be against mechanisms that only affected the behaviors of a > particular pair of SIP endpoints - not changing the behavior of the SIP servers at all. > Please adjust or remove this paragraph. > I've clarified this paragraph. The new version is below: Overload control for SIP servers is different from end-to-end congestion control used by transport protocols such as TCP. The traffic exchanged between SIP servers consists of many individual SIP messages. Each SIP message is typically created individually by a SIP UA (e.g., to start setting up a call) and each message has its own source and destination address. Even SIP messages containing identical SIP URIs (e.g., a SUBSCRIBE and a INVITE message to the same SIP URI) can be routed to different destinations. This is different from TCP which controls a large flow of packets (e.g., to transmit a file) between a single source and a single destination. If congestion occurs in a router, the sources can detect this condition and adjust the rate at which new packets are transmitted. > 4) The end of section 6 talks about asking UAs to wait using 503/retry-after. What > 503/retry-after does is ask the next upstream element to wait. I think it's the intention > to scope this discussion to the case where the UA _is_ the next upstream element, but that > needs to be made even more clear. The section should also discuss how an element knows > that the next upstream element is a UA and not another proxy. > For this case, it is not important that the upstream neighbor is a UA or a proxy. The key is that there are many upstream neighbors that each contribute only a few requests. Edge proxy to UA is probably the common scenario for this case. I've clarified the text. > 5) It would help to clarify in Section 9.1 (particularly paragraph 2) that "next request" > is "the start of another transaction", and not "retransmissions in any ongoing transaction". > Done. > 6) In section 9.3, I disagree that 100 Trying does not provide confirmation of receipt > of a message. That is _exactly_ what 100 Trying does, and its point is to affect the > transaction state machine's reliability mechanisms. It means it has been accepted for > processing - this hop is taking responsibility for it now. If you have an implementation > that would cause transaction reliability to fail by sending a 100 early in the processing > as you suggest, that implementation in not conformant to the specification. Are you > instead trying to say that the 100 Trying does not indicate that the message has > already been forwarded? > This is based on a discussion in the design team. It was pointed out that it is common practice in SIP implementations to create 100 Trying very early in the processing and that a message can still be dropped (e.g., from an overflowing buffer). Maybe someone who had the original comment can comment on this. I'd be happy to make the change as needed. > 7) Did you mean dialog instead of session in the first paragraph of section 12? Yes. > Surely we > have actual research backing up the claim "As a general rule". Can we point to that please? > The motivation for this recommendation is driven by user experience. Dropping mid-dialog requests will create a situation in which a user was, e.g., able to set up a call but is unable to modify it after that or terminate it. Targeting requests that initiate a dialog will, e.g., lead to calls that cannot be set up, which is more familiar to a user. > 8) The security consideration section should note what key security properties > each of the possible models have and what influence that could have on the mechanism > chosen, particularly when specific mechanics have been discussed in a model's section. > For instance, the mechanism detailed in the 4th paragraph of 9.1 is exposed if an attacker > can easily make a new server appear to appear (by sending one message perhaps), cutting > traffic at legitimate servers down by 1/n with each new malicious appearance. > I will address this comment in the next version of the draft. > Nits: > > Section 2 Paragraph 1 Sentence 1: s/to the SIP congestion collapse/to SIP congestion collapse/ > > Section 2 Paragraph 3: > - s/spend/spent/g. Suggest changing this sentence to "Discarding a SIP > message after spending the resources to parse it is expensive." > - s/less and less/fewer/, s/more and more/more/ > - s/slope/rate/ > > Section 6 Paragraph 5: s/determine much traffic/determine how much traffic/ > Done. Thanks! Volker > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From Internet-Drafts@ietf.org Thu Mar 10 18:45:03 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 277143A6B24; Thu, 10 Mar 2011 18:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVKPQGSIAWeo; Thu, 10 Mar 2011 18:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9DA03A67F2; Thu, 10 Mar 2011 18:45:01 -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: 3.12 Message-ID: <20110311024501.27888.97014.idtracker@localhost> Date: Thu, 10 Mar 2011 18:45:01 -0800 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action:draft-ietf-soc-overload-design-05.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 02:45:03 -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 : Design Considerations for Session Initiation Protocol (SIP) Overload Control Author(s) : V. Hilt, et al. Filename : draft-ietf-soc-overload-design-05.txt Pages : 23 Date : 2011-03-10 Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document discusses models and design considerations for a SIP overload control mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-soc-overload-design-05.txt 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-design-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-10184125.I-D@ietf.org> --NextPart-- From salvatore.loreto@ericsson.com Wed Mar 16 01:57:33 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D4693A68A7 for ; Wed, 16 Mar 2011 01:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aahAGc7h6iNO for ; Wed, 16 Mar 2011 01:57:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 180E43A6801 for ; Wed, 16 Mar 2011 01:57:31 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-ba-4d807bd1443a Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 23.61.09202.1DB708D4; Wed, 16 Mar 2011 09:58:57 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Wed, 16 Mar 2011 09:58:56 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C0A2E289B; Wed, 16 Mar 2011 10:58:56 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 89B3B50A1B; Wed, 16 Mar 2011 10:58:56 +0200 (EET) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3B2A35037F; Wed, 16 Mar 2011 10:58:56 +0200 (EET) Message-ID: <4D807BD0.7080200@ericsson.com> Date: Wed, 16 Mar 2011 10:58:56 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 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] SoC draft agenda for Prague IETF 80 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 08:57:33 -0000 Hi all, The initial draft agenda of SoC is available at: http://www.ietf.org/proceedings/80/agenda/soc.txt please contact Volker and me for changes or missing requests. cheers /Sal -- Salvatore Loreto www.sloreto.com From partr@cisco.com Wed Mar 16 17:43:14 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFE563A6906; Wed, 16 Mar 2011 17:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.292 X-Spam-Level: X-Spam-Status: No, score=-9.292 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvkuqOSQsEW0; Wed, 16 Mar 2011 17:43:13 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6BF2D3A68DE; Wed, 16 Mar 2011 17:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=3432; q=dns/txt; s=iport; t=1300322681; x=1301532281; h=mime-version:subject:date:message-id:from:to:cc; bh=q7Z1Mw4k7VXsAbRQJK5n80hCRWnpjLoGvTJDBJ3UT40=; b=Qj1MV8TR7M0V0LQwRDaBLcNxjlSbHtQ4HM5i+vrKeNAZJxJhb93P6ZRu Dq315jTYatZwvu1WmLMr0Qhn7FBBb8oJ9BtGSulKjmnQvuHg5Q7mTF49j Bi/GLiVu6GhNcinzAhp+gSwBYViCHi/xl+7q0YUpPGxO0veLSweMs1o22 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EAGr2gE2Q/khMgWdsb2JhbACkfFMUAQEWJiWmHpxegnuCaASFLYsE X-IronPort-AV: E=Sophos;i="4.63,196,1299456000"; d="scan'208,217";a="79530412" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2011 00:44:39 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2H0icJt008871; Thu, 17 Mar 2011 00:44:39 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 06:14:38 +0530 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_01CBE43C.7E7458A2" Date: Thu, 17 Mar 2011 06:14:38 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bar BOF request for SIP Load balancing & (media) overload handling Thread-Index: AcvkNQDWIeXRlo1yRRq3Yg+LUWi3ZA== From: "Parthasarathi R (partr)" To: , "Cullen Jennings (fluffy)" , "Mike Hammer (hmmr)" , , , , , "Paul Kyzivat (pkyzivat)" , , , , , , X-OriginalArrivalTime: 17 Mar 2011 00:44:38.0848 (UTC) FILETIME=[7EE7C400:01CBE43C] X-Mailman-Approved-At: Thu, 17 Mar 2011 06:19:12 -0700 Cc: dispatch@ietf.org, sip-overload@ietf.org Subject: [sip-overload] Bar BOF request for SIP Load balancing & (media) overload handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 00:43:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE43C.7E7458A2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 There is lot of discussion about SIP load balancing and overload = handling in Dispatch alias. I wish to have discussion about SIP Load = balancing & (media) overload handling at IETF-80 Prague. I guess that = Bar BOF is the idle way to start the discussion about this topic to = common understanding and identify the way to move forward. Please = suggest me in case any other mechanism exists in IETF. =20 I have included the folks who has shown the interest in this topic as = part of SIP Load balancing & overload handling, dispatch WG chairs, CCed = to Dispatch and SoC WG alias. AFAIK, the couple of drafts are related to = this problem: =20 draft-bessis-dispatch-adaptive-load-balancing-00 draft-partha-dispatch-sip-media-overload-control-00.txt draft-jones-sip-overload-sce-00 draft-partha-dispatch-resource-availability-00=20 draft-sparks-sipping-load-00 =20 Please let me about others interest and opinion to have Bar BOF for SIP = Load balancing & overload handling during IETF-80. =20 Thanks Partha ------_=_NextPart_001_01CBE43C.7E7458A2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
Hi all,
=0A=
 
=0A=
There is lot of discussion about SIP = load balancing and overload handling in Dispatch alias. I wish to have = discussion about SIP Load balancing & (media) overload handling at = IETF-80 Prague. I guess that Bar BOF is the idle way to start the = discussion about this topic to common understanding and identify the way = to move forward. Please suggest me in case any other mechanism exists in = IETF.
=0A=
 
=0A=
I have included the folks who has shown = the interest in this topic as part of SIP Load balancing & overload = handling, dispatch WG chairs, = CCed to Dispatch and SoC WG alias. AFAIK, the couple of drafts are = related to this problem:
=0A=
 
=0A=
draft-bessis-dispatch-adaptive-load-balancing-00
draft-pa= rtha-dispatch-sip-media-overload-control-00.txt
draft-jones-sip-overlo= ad-sce-00
draft-partha-dispatch-resource-availability-00 =
draft-sparks-sipping-load-00
=0A=
 
=0A=
Please let me about others interest and = opinion to have Bar BOF for SIP Load balancing & overload handling = during IETF-80.
=0A=
 
=0A=
Thanks
=0A=
Partha
------_=_NextPart_001_01CBE43C.7E7458A2-- From fluffy@cisco.com Wed Mar 16 19:14:19 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2BC3A68EF; Wed, 16 Mar 2011 19:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.754 X-Spam-Level: X-Spam-Status: No, score=-108.754 tagged_above=-999 required=5 tests=[AWL=1.845, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VUlzeEH4EcJ; Wed, 16 Mar 2011 19:14:18 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 689B93A68CE; Wed, 16 Mar 2011 19:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1289; q=dns/txt; s=iport; t=1300328146; x=1301537746; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=JOqP5k9E7v/2Nl3L8TqW3oinbfi4+HSVFB5WljN3NGU=; b=kgxSxF/DiC583a6ArBuYkKv35lnClG/8A0c4hAJmPNVXpE2cOSs2UOX7 UkSp16BC1gshMoZU6nup83QdxhMUkWPxuSJgNNAYdJuIKr3201A6gUokI 3DZM+avy5bdonr4l0uBi0h0zvgk1fcyxHuADeI1WlBaAyR0XFssexrxAO U=; X-IronPort-AV: E=Sophos;i="4.63,197,1299456000"; d="scan'208";a="226371636" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 17 Mar 2011 02:15:44 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2H2FgcT001648; Thu, 17 Mar 2011 02:15:42 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 16 Mar 2011 20:18:32 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Parthasarathi R (partr) X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Thu, 17 Mar 2011 06:19:12 -0700 Cc: dworley@avaya.com, vpascual@acmepacket.com, sip-overload@ietf.org, keith.drage@alcatel-lucent.com, HKaplan@acmepacket.com, dispatch@ietf.org, Thierry.Bessis@alcatel-lucent.com, "Mike Hammer \(hmmr\)" , spromano@unina.it Subject: Re: [sip-overload] Bar BOF request for SIP Load balancing & (media) overload handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 02:14:19 -0000 Just as FYI ... if you have not seen it, you might want to have a read = of=20 http://tools.ietf.org/html/draft-eggert-successful-bar-bof On Mar 16, 2011, at 6:44 PM, Parthasarathi R (partr) wrote: > Hi all, > =20 > There is lot of discussion about SIP load balancing and overload = handling in Dispatch alias. I wish to have discussion about SIP Load = balancing & (media) overload handling at IETF-80 Prague. I guess that = Bar BOF is the idle way to start the discussion about this topic to = common understanding and identify the way to move forward. Please = suggest me in case any other mechanism exists in IETF. > =20 > I have included the folks who has shown the interest in this topic as = part of SIP Load balancing & overload handling, dispatch WG chairs, CCed = to Dispatch and SoC WG alias. AFAIK, the couple of drafts are related to = this problem: > =20 > draft-bessis-dispatch-adaptive-load-balancing-00 > draft-partha-dispatch-sip-media-overload-control-00.txt > draft-jones-sip-overload-sce-00 > draft-partha-dispatch-resource-availability-00=20 > draft-sparks-sipping-load-00 > =20 > Please let me about others interest and opinion to have Bar BOF for = SIP Load balancing & overload handling during IETF-80. > =20 > Thanks > Partha From HKaplan@acmepacket.com Wed Mar 16 19:59:32 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B503A6A21; Wed, 16 Mar 2011 19:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=0.826, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CC6NpNwjcFRk; Wed, 16 Mar 2011 19:59:31 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A04CC3A6A1F; Wed, 16 Mar 2011 19:59:31 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 16 Mar 2011 23:00:57 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Wed, 16 Mar 2011 23:00:57 -0400 From: Hadriel Kaplan To: Cullen Jennings Date: Wed, 16 Mar 2011 23:00:55 -0400 Thread-Topic: Bar BOF request for SIP Load balancing & (media) overload handling Thread-Index: AcvkT4k3HPU5zNPIQb+aOQOg62ZNCw== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= X-Mailman-Approved-At: Thu, 17 Mar 2011 06:19:12 -0700 Cc: "dworley@avaya.com" , Victor Pascual , "sip-overload@ietf.org" , "keith.drage@alcatel-lucent.com" , "Thierry.Bessis@alcatel-lucent.com" , "dispatch@ietf.org" , "Mike Hammer \(hmmr\)" , "spromano@unina.it" Subject: Re: [sip-overload] Bar BOF request for SIP Load balancing & (media) overload handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 02:59:32 -0000 Lars should let Robert be the editor for this draft. That way it'll be "draft-sparks-successful-bar-bof" which would be a great = title. :) On Mar 16, 2011, at 10:18 PM, Cullen Jennings wrote: >=20 > Just as FYI ... if you have not seen it, you might want to have a read of= =20 > http://tools.ietf.org/html/draft-eggert-successful-bar-bof >=20 >=20 > On Mar 16, 2011, at 6:44 PM, Parthasarathi R (partr) wrote: >=20 >> Hi all, >>=20 >> There is lot of discussion about SIP load balancing and overload handlin= g in Dispatch alias. I wish to have discussion about SIP Load balancing & (= media) overload handling at IETF-80 Prague. I guess that Bar BOF is the idl= e way to start the discussion about this topic to common understanding and = identify the way to move forward. Please suggest me in case any other mecha= nism exists in IETF. >>=20 >> I have included the folks who has shown the interest in this topic as pa= rt of SIP Load balancing & overload handling, dispatch WG chairs, CCed to D= ispatch and SoC WG alias. AFAIK, the couple of drafts are related to this p= roblem: >>=20 >> draft-bessis-dispatch-adaptive-load-balancing-00 >> draft-partha-dispatch-sip-media-overload-control-00.txt >> draft-jones-sip-overload-sce-00 >> draft-partha-dispatch-resource-availability-00=20 >> draft-sparks-sipping-load-00 >>=20 >> Please let me about others interest and opinion to have Bar BOF for SIP = Load balancing & overload handling during IETF-80. >>=20 >> Thanks >> Partha >=20 From partr@cisco.com Wed Mar 16 23:45:12 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DBB03A69F9; Wed, 16 Mar 2011 23:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.988 X-Spam-Level: X-Spam-Status: No, score=-9.988 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qg4vygPszW8; Wed, 16 Mar 2011 23:45:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B54D63A6A3E; Wed, 16 Mar 2011 23:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=1976; q=dns/txt; s=iport; t=1300344398; x=1301553998; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=m6V5eb/BEfUcqY3m6Bp4G4GuyNajC/6lLF0lm4PxPXg=; b=PycEg9YHaV8Gyce2Jqb0qARtnqvneshuKaK4n+xf5uvtaP0zgDGUXBrG NydhHaBWU2yfmQccffqesJqiNFYKi+Sy/lLRZNZ/WzVodw8mL0s3F6KfF dEHPE0aIS6lC5pZ5cMXVGEs5yDo+Q9qzmkY4Zjj7Ah5tUHKW9QMjmaDJ7 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0BAI5KgU2Q/khNgWdsb2JhbACYHI00FAEBFiYlpnecOYJ7gmgEhS2LBIMg X-IronPort-AV: E=Sophos;i="4.63,198,1299456000"; d="scan'208";a="79561966" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2011 06:46:37 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2H6kZfe023734; Thu, 17 Mar 2011 06:46:37 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 12:16:36 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Mar 2011 12:16:34 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bar BOF request for SIP Load balancing & (media) overload handling Thread-Index: AcvkSUOra49E6+DAT4KXcWQYYlvlegAJXRHQ References: From: "Parthasarathi R (partr)" To: "Cullen Jennings (fluffy)" X-OriginalArrivalTime: 17 Mar 2011 06:46:36.0037 (UTC) FILETIME=[0F5BD350:01CBE46F] X-Mailman-Approved-At: Thu, 17 Mar 2011 06:19:12 -0700 Cc: dworley@avaya.com, vpascual@acmepacket.com, sip-overload@ietf.org, keith.drage@alcatel-lucent.com, HKaplan@acmepacket.com, dispatch@ietf.org, Thierry.Bessis@alcatel-lucent.com, "Mike Hammer \(hmmr\)" , spromano@unina.it Subject: Re: [sip-overload] Bar BOF request for SIP Load balancing & (media) overload handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 06:45:12 -0000 Cullen, Thanks for forwarding the document. The draft is informative for newcomers like me. Thanks Partha -----Original Message----- From: Cullen Jennings (fluffy)=20 Sent: Thursday, March 17, 2011 7:49 AM To: Parthasarathi R (partr) Cc: dworley@avaya.com; Mike Hammer (hmmr); HKaplan@acmepacket.com; keith.drage@alcatel-lucent.com; john.elwell@siemens-enterprise.com; mary.ietf.barnes@gmail.com; Paul Kyzivat (pkyzivat); paulej@packetizer.com; rjsparks@nostrum.com; spromano@unina.it; Thierry.Bessis@alcatel-lucent.com; vkg@bell-labs.com; vpascual@acmepacket.com; dispatch@ietf.org; sip-overload@ietf.org Subject: Re: Bar BOF request for SIP Load balancing & (media) overload handling Just as FYI ... if you have not seen it, you might want to have a read of http://tools.ietf.org/html/draft-eggert-successful-bar-bof On Mar 16, 2011, at 6:44 PM, Parthasarathi R (partr) wrote: > Hi all, > =20 > There is lot of discussion about SIP load balancing and overload handling in Dispatch alias. I wish to have discussion about SIP Load balancing & (media) overload handling at IETF-80 Prague. I guess that Bar BOF is the idle way to start the discussion about this topic to common understanding and identify the way to move forward. Please suggest me in case any other mechanism exists in IETF. > =20 > I have included the folks who has shown the interest in this topic as part of SIP Load balancing & overload handling, dispatch WG chairs, CCed to Dispatch and SoC WG alias. AFAIK, the couple of drafts are related to this problem: > =20 > draft-bessis-dispatch-adaptive-load-balancing-00 > draft-partha-dispatch-sip-media-overload-control-00.txt > draft-jones-sip-overload-sce-00 > draft-partha-dispatch-resource-availability-00=20 > draft-sparks-sipping-load-00 > =20 > Please let me about others interest and opinion to have Bar BOF for SIP Load balancing & overload handling during IETF-80. > =20 > Thanks > Partha From paulej@packetizer.com Thu Mar 17 05:36:57 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09633A68BF; Thu, 17 Mar 2011 05:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yk5xG5Vco7m7; Thu, 17 Mar 2011 05:36:56 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by core3.amsl.com (Postfix) with ESMTP id B24A23A68BD; Thu, 17 Mar 2011 05:36:55 -0700 (PDT) Received: from [156.106.218.43] ([156.106.218.43]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p2HCc455002750 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 17 Mar 2011 08:38:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1300365494; bh=UWhOm4FjXF8YHjrGGr2EQn3fnPA5xbQ/bkRFtrOCe5c=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=QKQVgZNqGWC2l6XpHGfioxDEoaC9sjQrdyeB/wMgev4S9tsG0dMAkMvFINug+lGiJ /grM5fYKXV234lLalP67+lp68HXbRlpB9XxI1CI1/rCH5i5/wMKmSAJl/kOZD4FVBy EoZJOekJ1WwaHNjA1HJWFLQzSv5WrllkHWyHWv5g= Message-ID: <4D8200AC.5070307@packetizer.com> Date: Thu, 17 Mar 2011 08:38:04 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 17 Mar 2011 06:19:12 -0700 Cc: dworley@avaya.com, vpascual@acmepacket.com, sip-overload@ietf.org, keith.drage@alcatel-lucent.com, HKaplan@acmepacket.com, dispatch@ietf.org, Thierry.Bessis@alcatel-lucent.com, "Mike Hammer \(hmmr\)" , spromano@unina.it Subject: Re: [sip-overload] Bar BOF request for SIP Load balancing & (media) overload handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 12:36:57 -0000 This is not entirely helpful. It does not go into explaining what kind or how much beer Partha is going to be required to buy everyone who attends ;-) On 3/16/2011 10:18 PM, Cullen Jennings wrote: > Just as FYI ... if you have not seen it, you might want to have a read of > http://tools.ietf.org/html/draft-eggert-successful-bar-bof > > > On Mar 16, 2011, at 6:44 PM, Parthasarathi R (partr) wrote: > >> Hi all, >> >> There is lot of discussion about SIP load balancing and overload handling in Dispatch alias. I wish to have discussion about SIP Load balancing& (media) overload handling at IETF-80 Prague. I guess that Bar BOF is the idle way to start the discussion about this topic to common understanding and identify the way to move forward. Please suggest me in case any other mechanism exists in IETF. >> >> I have included the folks who has shown the interest in this topic as part of SIP Load balancing& overload handling, dispatch WG chairs, CCed to Dispatch and SoC WG alias. AFAIK, the couple of drafts are related to this problem: >> >> draft-bessis-dispatch-adaptive-load-balancing-00 >> draft-partha-dispatch-sip-media-overload-control-00.txt >> draft-jones-sip-overload-sce-00 >> draft-partha-dispatch-resource-availability-00 >> draft-sparks-sipping-load-00 >> >> Please let me about others interest and opinion to have Bar BOF for SIP Load balancing& overload handling during IETF-80. >> >> Thanks >> Partha From jgunn6@csc.com Thu Mar 17 07:25:17 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D07423A6A08; Thu, 17 Mar 2011 07:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaQDYgHPr+wg; Thu, 17 Mar 2011 07:25:15 -0700 (PDT) Received: from mail63.messagelabs.com (mail63.messagelabs.com [216.82.242.83]) by core3.amsl.com (Postfix) with ESMTP id 245143A6827; Thu, 17 Mar 2011 07:25:14 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-15.tower-63.messagelabs.com!1300371900!134876145!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 28877 invoked from network); 17 Mar 2011 14:25:00 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-15.tower-63.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Mar 2011 14:25:00 -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.3.3mp) with ESMTP id p2HEOdCv006438; Thu, 17 Mar 2011 10:24:57 -0400 In-Reply-To: References: To: "Parthasarathi R (partr)" MIME-Version: 1.0 X-KeepSent: CEDB53D9:C5DB51F1-85257856:004EFA4D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Thu, 17 Mar 2011 10:24:49 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP1 HF29|January 09, 2011) at 03/17/2011 10:23:59 AM, Serialize complete at 03/17/2011 10:23:59 AM Content-Type: multipart/alternative; boundary="=_alternative 004F2DB185257856_=" X-Mailman-Approved-At: Thu, 17 Mar 2011 08:09:28 -0700 Cc: dworley@avaya.com, dispatch@ietf.org, sip-overload@ietf.org, keith.drage@alcatel-lucent.com, dispatch-bounces@ietf.org, HKaplan@acmepacket.com, vpascual@acmepacket.com, Thierry.Bessis@alcatel-lucent.com, "Mike Hammer \(hmmr\)" , spromano@unina.it Subject: Re: [sip-overload] [dispatch] Bar BOF request for SIP Load balancing & (media) overload handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 14:25:18 -0000 This is a multipart message in MIME format. --=_alternative 004F2DB185257856_= Content-Type: text/plain; charset="US-ASCII" Partha, I am definitely interested in the subject, but I will, unfortunately, not be in Prague. If it were possible to hold the bar bof somewhere with an audio feed and jabber room, I would definitely participate remotely. Thanks Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: "Parthasarathi R (partr)" To: , "Cullen Jennings (fluffy)" , "Mike Hammer (hmmr)" , , , , , "Paul Kyzivat (pkyzivat)" , , , , , , Cc: dispatch@ietf.org, sip-overload@ietf.org Date: 03/16/2011 11:34 PM Subject: [dispatch] Bar BOF request for SIP Load balancing & (media) overload handling Hi all, There is lot of discussion about SIP load balancing and overload handling in Dispatch alias. I wish to have discussion about SIP Load balancing & (media) overload handling at IETF-80 Prague. I guess that Bar BOF is the idle way to start the discussion about this topic to common understanding and identify the way to move forward. Please suggest me in case any other mechanism exists in IETF. I have included the folks who has shown the interest in this topic as part of SIP Load balancing & overload handling, dispatch WG chairs, CCed to Dispatch and SoC WG alias. AFAIK, the couple of drafts are related to this problem: draft-bessis-dispatch-adaptive-load-balancing-00 draft-partha-dispatch-sip-media-overload-control-00.txt draft-jones-sip-overload-sce-00 draft-partha-dispatch-resource-availability-00 draft-sparks-sipping-load-00 Please let me about others interest and opinion to have Bar BOF for SIP Load balancing & overload handling during IETF-80. Thanks Partha_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --=_alternative 004F2DB185257856_= Content-Type: text/html; charset="US-ASCII"
Partha,

I am definitely interested in the subject, but I will, unfortunately, not be in Prague.

If it were possible to hold the bar bof somewhere with an audio feed and jabber room, I would definitely participate remotely.

Thanks

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.


From: "Parthasarathi R (partr)" <partr@cisco.com>
To: <dworley@avaya.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>, "Mike Hammer (hmmr)" <hmmr@cisco.com>, <HKaplan@acmepacket.com>, <keith.drage@alcatel-lucent.com>, <john.elwell@siemens-enterprise.com>, <mary.ietf.barnes@gmail.com>, "Paul Kyzivat (pkyzivat)" <pkyzivat@cisco.com>, <paulej@packetizer.com>, <rjsparks@nostrum.com>, <spromano@unina.it>, <Thierry.Bessis@alcatel-lucent.com>, <vkg@bell-labs.com>, <vpascual@acmepacket.com>
Cc: dispatch@ietf.org, sip-overload@ietf.org
Date: 03/16/2011 11:34 PM
Subject: [dispatch] Bar BOF request for SIP Load balancing & (media)        overload handling




Hi all,
 
There is lot of discussion about SIP load balancing and overload handling in Dispatch alias. I wish to have discussion about SIP Load balancing & (media) overload handling at IETF-80 Prague. I guess that Bar BOF is the idle way to start the discussion about this topic to common understanding and identify the way to move forward. Please suggest me in case any other mechanism exists in IETF.
 
I have included the folks who has shown the interest in this topic as part of SIP Load balancing & overload handling, dispatch WG chairs, CCed to Dispatch and SoC WG alias. AFAIK, the couple of drafts are related to this problem:
 
draft-bessis-dispatch-adaptive-load-balancing-00
draft-partha-dispatch-sip-media-overload-control-00.txt
draft-jones-sip-overload-sce-00
draft-partha-dispatch-resource-availability-00
draft-sparks-sipping-load-00
 
Please let me about others interest and opinion to have Bar BOF for SIP Load balancing & overload handling during IETF-80.
 
Thanks
Partha_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--=_alternative 004F2DB185257856_=-- From dworley@avaya.com Thu Mar 17 08:21:52 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AD803A6968; Thu, 17 Mar 2011 08:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GCL92V0vk29; Thu, 17 Mar 2011 08:21:50 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id B567D3A6920; Thu, 17 Mar 2011 08:21:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFMtcU2HCzI1/2dsb2JhbACmZXSkeQKZFoVhBJAM X-IronPort-AV: E=Sophos;i="4.63,199,1299474000"; d="scan'208";a="269962120" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Mar 2011 11:23:17 -0400 X-IronPort-AV: E=Sophos;i="4.63,199,1299474000"; d="scan'208";a="623980768" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 17 Mar 2011 11:23:17 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 17 Mar 2011 11:23:17 -0400 From: "Worley, Dale R (Dale)" To: "Parthasarathi R (partr)" , "Cullen Jennings (fluffy)" , "Mike Hammer (hmmr)" , "HKaplan@acmepacket.com" , "keith.drage@alcatel-lucent.com" , "john.elwell@siemens-enterprise.com" , "mary.ietf.barnes@gmail.com" , "Paul Kyzivat (pkyzivat)" , "paulej@packetizer.com" , "rjsparks@nostrum.com" , "spromano@unina.it" , "Thierry.Bessis@alcatel-lucent.com" , "vkg@bell-labs.com" , "vpascual@acmepacket.com" Date: Thu, 17 Mar 2011 11:22:29 -0400 Thread-Topic: Bar BOF request for SIP Load balancing & (media) overload handling Thread-Index: AcvkNQDWIeXRlo1yRRq3Yg+LUWi3ZAAgh/mh Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 17 Mar 2011 08:23:07 -0700 Cc: "dispatch@ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] Bar BOF request for SIP Load balancing & (media) overload handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 15:21:52 -0000 ________________________________________ From: Parthasarathi R (partr) [partr@cisco.com] Please let me about others interest and opinion to have Bar BOF for SIP Loa= d balancing & overload handling during IETF-80. ________________________________________ Clearly, this is a subject that needs study within the IETF, so the bar BOF= is a very good idea. (I'll be at IETF Prague.) Dale From gsalguei@cisco.com Thu Mar 17 08:27:40 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 212593A6968; Thu, 17 Mar 2011 08:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.418 X-Spam-Level: X-Spam-Status: No, score=-10.418 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aB0kVpJo0eJn; Thu, 17 Mar 2011 08:27:38 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 272A93A68FC; Thu, 17 Mar 2011 08:27:38 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2HFSwhX015862; Thu, 17 Mar 2011 11:28:59 -0400 (EDT) Received: from dhcp-64-102-211-8.cisco.com (dhcp-64-102-211-8.cisco.com [64.102.211.8]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2HFSvLl006267; Thu, 17 Mar 2011 11:28:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-72--54009375 From: Gonzalo Salgueiro In-Reply-To: Date: Thu, 17 Mar 2011 11:28:57 -0400 Message-Id: <74D7A7C9-A12B-4CBB-8186-A4314A4CEDF5@cisco.com> References: To: Janet P Gunn X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Thu, 17 Mar 2011 08:36:31 -0700 Cc: dispatch@ietf.org, sip-overload@ietf.org, keith.drage@alcatel-lucent.com, HKaplan@acmepacket.com, vpascual@acmepacket.com, Thierry.Bessis@alcatel-lucent.com, dispatch-bounces@ietf.org Subject: Re: [sip-overload] [dispatch] Bar BOF request for SIP Load balancing & (media) overload handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 15:27:40 -0000 --Apple-Mail-72--54009375 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is my situation as well. I would love to join but will not be in = attendance. Gonzalo On Mar 17, 2011, at 10:24 AM, Janet P Gunn wrote: >=20 > Partha,=20 >=20 > I am definitely interested in the subject, but I will, unfortunately, = not be in Prague.=20 >=20 > If it were possible to hold the bar bof somewhere with an audio feed = and jabber room, I would definitely participate remotely.=20 >=20 > Thanks=20 >=20 > Janet >=20 > This is a PRIVATE message. If you are not the intended recipient, = please delete without copying and kindly advise us by e-mail of the = mistake in delivery.=20 > NOTE: Regardless of content, this e-mail shall not operate to bind CSC = to any order or other contract unless pursuant to explicit written = agreement or government initiative expressly permitting the use of = e-mail for such purpose.=20 >=20 >=20 > From: "Parthasarathi R (partr)" > To: , "Cullen Jennings (fluffy)" = , "Mike Hammer (hmmr)" , = , , = , , = "Paul Kyzivat (pkyzivat)" , , = , , = , , = > Cc: dispatch@ietf.org, sip-overload@ietf.org > Date: 03/16/2011 11:34 PM > Subject: [dispatch] Bar BOF request for SIP Load balancing & = (media) overload handling >=20 >=20 >=20 >=20 > Hi all,=20 > =20 > There is lot of discussion about SIP load balancing and overload = handling in Dispatch alias. I wish to have discussion about SIP Load = balancing & (media) overload handling at IETF-80 Prague. I guess that = Bar BOF is the idle way to start the discussion about this topic to = common understanding and identify the way to move forward. Please = suggest me in case any other mechanism exists in IETF.=20 > =20 > I have included the folks who has shown the interest in this topic as = part of SIP Load balancing & overload handling, dispatch WG chairs, CCed = to Dispatch and SoC WG alias. AFAIK, the couple of drafts are related to = this problem:=20 > =20 > draft-bessis-dispatch-adaptive-load-balancing-00 > draft-partha-dispatch-sip-media-overload-control-00.txt > draft-jones-sip-overload-sce-00 > draft-partha-dispatch-resource-availability-00=20 > draft-sparks-sipping-load-00=20 > =20 > Please let me about others interest and opinion to have Bar BOF for = SIP Load balancing & overload handling during IETF-80.=20 > =20 > Thanks=20 > Partha_______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail-72--54009375 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii This is my situation as well. I would love to join but will not be in attendance.

Gonzalo

On Mar 17, 2011, at 10:24 AM, Janet P Gunn wrote:


Partha,

I am definitely interested in the subject, but I will, unfortunately, not be in Prague.

If it were possible to hold the bar bof somewhere with an audio feed and jabber room, I would definitely participate remotely.

Thanks

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.


From: "Parthasarathi R (partr)" <partr@cisco.com>
To: <dworley@avaya.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>, "Mike Hammer (hmmr)" <hmmr@cisco.com>, <HKaplan@acmepacket.com>, <keith.drage@alcatel-lucent.com>, <john.elwell@siemens-enterprise.com>, <mary.ietf.barnes@gmail.com>, "Paul Kyzivat (pkyzivat)" <pkyzivat@cisco.com>, <paulej@packetizer.com>, <rjsparks@nostrum.com>, <spromano@unina.it>, <Thierry.Bessis@alcatel-lucent.com>, <vkg@bell-labs.com>, <vpascual@acmepacket.com>
Cc: dispatch@ietf.org, sip-overload@ietf.org
Date: 03/16/2011 11:34 PM
Subject: [dispatch] Bar BOF request for SIP Load balancing & (media)        overload handling




Hi all,
 
There is lot of discussion about SIP load balancing and overload handling in Dispatch alias. I wish to have discussion about SIP Load balancing & (media) overload handling at IETF-80 Prague. I guess that Bar BOF is the idle way to start the discussion about this topic to common understanding and identify the way to move forward. Please suggest me in case any other mechanism exists in IETF.
 
I have included the folks who has shown the interest in this topic as part of SIP Load balancing & overload handling, dispatch WG chairs, CCed to Dispatch and SoC WG alias. AFAIK, the couple of drafts are related to this problem:
 
draft-bessis-dispatch-adaptive-load-balancing-00
draft-partha-dispatch-sip-media-overload-control-00.txt
draft-jones-sip-overload-sce-00
draft-partha-dispatch-resource-availability-00
draft-sparks-sipping-load-00
 
Please let me about others interest and opinion to have Bar BOF for SIP Load balancing & overload handling during IETF-80.
 
Thanks
Partha_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--Apple-Mail-72--54009375-- From md3135@att.com Thu Mar 17 08:45:05 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A3AB3A6978; Thu, 17 Mar 2011 08:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uc0mx2KRgvV3; Thu, 17 Mar 2011 08:45:04 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 906C93A6968; Thu, 17 Mar 2011 08:45:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-8.tower-120.messagelabs.com!1300376790!8348950!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 30568 invoked from network); 17 Mar 2011 15:46:31 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-8.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Mar 2011 15:46:31 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p2HFjWAM025655; Thu, 17 Mar 2011 11:45:32 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p2HFjRw4025578; Thu, 17 Mar 2011 11:45:28 -0400 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_01CBE4BA.78E69453" Date: Thu, 17 Mar 2011 11:46:24 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA096F3937@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip-overload] Bar BOF request for SIP Load balancing & (media)overload handling Thread-Index: AcvkNQDWIeXRlo1yRRq3Yg+LUWi3ZAAhW4Hw References: From: "DOLLY, MARTIN C (ATTSI)" To: "Parthasarathi R (partr)" , , "Cullen Jennings (fluffy)" , "Mike Hammer (hmmr)" , , , , , "Paul Kyzivat (pkyzivat)" , , , , , , X-Mailman-Approved-At: Thu, 17 Mar 2011 10:25:35 -0700 Cc: dispatch@ietf.org, sip-overload@ietf.org Subject: Re: [sip-overload] Bar BOF request for SIP Load balancing & (media)overload handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 15:45:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE4BA.78E69453 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would be interested. Thank you. =20 From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of Parthasarathi R (partr) Sent: Wednesday, March 16, 2011 8:45 PM To: dworley@avaya.com; Cullen Jennings (fluffy); Mike Hammer (hmmr); HKaplan@acmepacket.com; keith.drage@alcatel-lucent.com; john.elwell@siemens-enterprise.com; mary.ietf.barnes@gmail.com; Paul Kyzivat (pkyzivat); paulej@packetizer.com; rjsparks@nostrum.com; spromano@unina.it; Thierry.Bessis@alcatel-lucent.com; vkg@bell-labs.com; vpascual@acmepacket.com Cc: dispatch@ietf.org; sip-overload@ietf.org Subject: [sip-overload] Bar BOF request for SIP Load balancing & (media)overload handling =20 Hi all, =20 There is lot of discussion about SIP load balancing and overload handling in Dispatch alias. I wish to have discussion about SIP Load balancing & (media) overload handling at IETF-80 Prague. I guess that Bar BOF is the idle way to start the discussion about this topic to common understanding and identify the way to move forward. Please suggest me in case any other mechanism exists in IETF. =20 I have included the folks who has shown the interest in this topic as part of SIP Load balancing & overload handling, dispatch WG chairs, CCed to Dispatch and SoC WG alias. AFAIK, the couple of drafts are related to this problem: =20 draft-bessis-dispatch-adaptive-load-balancing-00 draft-partha-dispatch-sip-media-overload-control-00.txt draft-jones-sip-overload-sce-00 draft-partha-dispatch-resource-availability-00=20 draft-sparks-sipping-load-00 =20 Please let me about others interest and opinion to have Bar BOF for SIP Load balancing & overload handling during IETF-80. =20 Thanks Partha ------_=_NextPart_001_01CBE4BA.78E69453 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would be interested. Thank you.

 

From:= = sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of Parthasarathi R (partr)
Sent: Wednesday, = March 16, 2011 8:45 PM
To: dworley@avaya.com; Cullen Jennings = (fluffy); Mike Hammer (hmmr); HKaplan@acmepacket.com; = keith.drage@alcatel-lucent.com; john.elwell@siemens-enterprise.com; = mary.ietf.barnes@gmail.com; Paul Kyzivat (pkyzivat); = paulej@packetizer.com; rjsparks@nostrum.com; spromano@unina.it; = Thierry.Bessis@alcatel-lucent.com; vkg@bell-labs.com; = vpascual@acmepacket.com
Cc: dispatch@ietf.org; = sip-overload@ietf.org
Subject: [sip-overload] Bar BOF request = for SIP Load balancing & (media)overload = handling

 

H= i all,

&= nbsp;

T= here is lot of discussion about SIP load balancing and overload handling = in Dispatch alias. I wish to have discussion about SIP Load balancing = & (media) overload handling at IETF-80 Prague. I guess that Bar BOF = is the idle way to start the discussion about this topic to common = understanding and identify the way to move forward. Please suggest me in = case any other mechanism exists in = IETF.

&= nbsp;

I= have included the folks who has shown the interest in this topic as = part of SIP Load balancing & overload handling, dispatch WG chairs, = CCed to Dispatch and SoC WG alias. AFAIK, the couple of drafts are = related to this problem:

&= nbsp;

d= raft-bessis-dispatch-adaptive-load-balancing-00
draft-partha-dispatch-= sip-media-overload-control-00.txt
draft-jones-sip-overload-sce-00
d= raft-partha-dispatch-resource-availability-00 =
draft-sparks-sipping-load-00

&= nbsp;

P= lease let me about others interest and opinion to have Bar BOF for SIP = Load balancing & overload handling during = IETF-80.

&= nbsp;

T= hanks

P= artha

------_=_NextPart_001_01CBE4BA.78E69453-- From mary.ietf.barnes@gmail.com Thu Mar 17 10:28:08 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FFED3A6AC9 for ; Thu, 17 Mar 2011 10:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.889 X-Spam-Level: X-Spam-Status: No, score=-102.889 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQyvlUWD6mcU for ; Thu, 17 Mar 2011 10:28:07 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 5311C3A69EB for ; Thu, 17 Mar 2011 10:28:07 -0700 (PDT) Received: by vxg33 with SMTP id 33so3313313vxg.31 for ; Thu, 17 Mar 2011 10:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wtMaxTo9gzUryDUq4NN5HU96Z0qTFgX860rjKGdrI+Q=; b=tbqMnl/yDQ+c+HzQlpLDvsMv2g/R6CHuQUkoNsR9IDijOYstYmo7rgAbxnofVVQHOB M1TUzuAqVfoIqU19Ur5UqIEFuabNM+x42Kyva91xWdWJii2KkcON1I+9E4dVzpM+8a77 vH5TpHH0V2MYBL5cr/zT9jxG8VckrvPiZA5lU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hYQ27MfM7DIIjyLeUQH+rLPRZi2l11y0WqjqYXAa/IeZrd/g7XoWKf9sgr7tEu8Ss3 q8pJ99i5asaa+oQThQpQYWw5aohE+c6Tr9oIp3B2YPez4ixL3e5wGFkthl4EVsAqQDFh Q2GEQzyUg+39nFcMLcPj3Y3ebvPmhT9VpEZw0= MIME-Version: 1.0 Received: by 10.52.69.46 with SMTP id b14mr61430vdu.103.1300382951578; Thu, 17 Mar 2011 10:29:11 -0700 (PDT) Received: by 10.52.167.137 with HTTP; Thu, 17 Mar 2011 10:29:11 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 Mar 2011 12:29:11 -0500 Message-ID: From: Mary Barnes To: sip-overload@ietf.org Content-Type: multipart/alternative; boundary=20cf307d03bae69ff6049eb0ffce Subject: Re: [sip-overload] Bar BOF request for SIP Load balancing & (media) overload handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 17:28:08 -0000 --20cf307d03bae69ff6049eb0ffce Content-Type: text/plain; charset=ISO-8859-1 Can I ask folks to PLEASE just keep this discussion on the DISPATCH mailing list only and trim the receiver list? My mailbox is filling up with moderator actions due to the many recipients and cross posting to multi-WGs fills up everyone's mailboxes. Note, I'm sending this email separately to each WG. Thanks, Mary. On Thu, Mar 17, 2011 at 10:22 AM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: Parthasarathi R (partr) [partr@cisco.com] > > Please let me about others interest and opinion to have Bar BOF for SIP > Load balancing & overload handling during IETF-80. > ________________________________________ > --20cf307d03bae69ff6049eb0ffce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Can I ask folks to PLEASE just keep this discussion on the DISPATCH mailing= list only and trim the receiver list? =A0My mailbox is filling up with mod= erator actions due to the many recipients and cross posting to multi-WGs fi= lls up everyone's mailboxes.

Note, I'm sending this email separately to each WG.
<= div>
Thanks,
Mary.=A0

On Thu, Mar 17, 2011 at 10:22 AM, Worley, Dale R (Dale) <dworley@avaya.com> wrote:
________________________________________ From: Parthasarathi R (partr) [partr@cis= co.com]

Please let me about others interest and opinion to have Bar BOF for SIP Loa= d balancing & overload handling during IETF-80.
________________________________________
= --20cf307d03bae69ff6049eb0ffce-- From salvatore.loreto@ericsson.com Thu Mar 17 10:26:51 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBEDE3A6ADC; Thu, 17 Mar 2011 10:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoZ4Bw10SIoP; Thu, 17 Mar 2011 10:26:49 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 303193A69F3; Thu, 17 Mar 2011 10:26:49 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-85-4d8244afdfc3 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 12.4C.09202.FA4428D4; Thu, 17 Mar 2011 18:28:16 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Thu, 17 Mar 2011 18:28:15 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 536D3249B; Thu, 17 Mar 2011 19:28:15 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 10E4750A75; Thu, 17 Mar 2011 19:28:15 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 374C350A72; Thu, 17 Mar 2011 19:28:14 +0200 (EET) Message-ID: <4D8244AD.40200@ericsson.com> Date: Thu, 17 Mar 2011 19:28:13 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "DOLLY, MARTIN C (ATTSI)" References: <14C85D6CCBE92743AF33663BF5D24EBA096F3937@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA096F3937@gaalpa1msgusr7e.ugd.att.com> Content-Type: multipart/alternative; boundary="------------000101040901050704020900" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Thu, 17 Mar 2011 10:45:54 -0700 Cc: "dworley@avaya.com" , "vpascual@acmepacket.com" , "sip-overload@ietf.org" , "keith.drage@alcatel-lucent.com" , "HKaplan@acmepacket.com" , "dispatch@ietf.org" , "Thierry.Bessis@alcatel-lucent.com" , "Mike Hammer \(hmmr\)" , "spromano@unina.it" Subject: Re: [sip-overload] Bar BOF request for SIP Load balancing & (media)overload handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 17:26:51 -0000 --------------000101040901050704020900 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit +1 On 3/17/11 5:46 PM, DOLLY, MARTIN C (ATTSI) wrote: > > I would be interested. Thank you. > > *From:*sip-overload-bounces@ietf.org > [mailto:sip-overload-bounces@ietf.org] *On Behalf Of *Parthasarathi R > (partr) > *Sent:* Wednesday, March 16, 2011 8:45 PM > *To:* dworley@avaya.com; Cullen Jennings (fluffy); Mike Hammer (hmmr); > HKaplan@acmepacket.com; keith.drage@alcatel-lucent.com; > john.elwell@siemens-enterprise.com; mary.ietf.barnes@gmail.com; Paul > Kyzivat (pkyzivat); paulej@packetizer.com; rjsparks@nostrum.com; > spromano@unina.it; Thierry.Bessis@alcatel-lucent.com; > vkg@bell-labs.com; vpascual@acmepacket.com > *Cc:* dispatch@ietf.org; sip-overload@ietf.org > *Subject:* [sip-overload] Bar BOF request for SIP Load balancing & > (media)overload handling > > Hi all, > > There is lot of discussion about SIP load balancing and overload > handling in Dispatch alias. I wish to have discussion about SIP Load > balancing & (media) overload handling at IETF-80 Prague. I guess that > Bar BOF is the idle way to start the discussion about this topic to > common understanding and identify the way to move forward. Please > suggest me in case any other mechanism exists in IETF. > > I have included the folks who has shown the interest in this topic as > part of SIP Load balancing & overload handling, dispatch WG chairs, > CCed to Dispatch and SoC WG alias. AFAIK, the couple of drafts are > related to this problem: > > draft-bessis-dispatch-adaptive-load-balancing-00 > draft-partha-dispatch-sip-media-overload-control-00.txt > draft-jones-sip-overload-sce-00 > draft-partha-dispatch-resource-availability-00 > draft-sparks-sipping-load-00 > > Please let me about others interest and opinion to have Bar BOF for > SIP Load balancing & overload handling during IETF-80. > > Thanks > > Partha > -- Salvatore Loreto www.sloreto.com --------------000101040901050704020900 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit +1

On 3/17/11 5:46 PM, DOLLY, MARTIN C (ATTSI) wrote:

I would be interested. Thank you.

 

From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of Parthasarathi R (partr)
Sent: Wednesday, March 16, 2011 8:45 PM
To: dworley@avaya.com; Cullen Jennings (fluffy); Mike Hammer (hmmr); HKaplan@acmepacket.com; keith.drage@alcatel-lucent.com; john.elwell@siemens-enterprise.com; mary.ietf.barnes@gmail.com; Paul Kyzivat (pkyzivat); paulej@packetizer.com; rjsparks@nostrum.com; spromano@unina.it; Thierry.Bessis@alcatel-lucent.com; vkg@bell-labs.com; vpascual@acmepacket.com
Cc: dispatch@ietf.org; sip-overload@ietf.org
Subject: [sip-overload] Bar BOF request for SIP Load balancing & (media)overload handling

 

Hi all,

 

There is lot of discussion about SIP load balancing and overload handling in Dispatch alias. I wish to have discussion about SIP Load balancing & (media) overload handling at IETF-80 Prague. I guess that Bar BOF is the idle way to start the discussion about this topic to common understanding and identify the way to move forward. Please suggest me in case any other mechanism exists in IETF.

 

I have included the folks who has shown the interest in this topic as part of SIP Load balancing & overload handling, dispatch WG chairs, CCed to Dispatch and SoC WG alias. AFAIK, the couple of drafts are related to this problem:

 

draft-bessis-dispatch-adaptive-load-balancing-00
draft-partha-dispatch-sip-media-overload-control-00.txt
draft-jones-sip-overload-sce-00
draft-partha-dispatch-resource-availability-00
draft-sparks-sipping-load-00

 

Please let me about others interest and opinion to have Bar BOF for SIP Load balancing & overload handling during IETF-80.

 

Thanks

Partha



-- 
Salvatore Loreto
www.sloreto.com
--------------000101040901050704020900-- From vpascual@acmepacket.com Thu Mar 17 11:15:11 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BBB23A6A1C; Thu, 17 Mar 2011 11:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIluk9SKdG0X; Thu, 17 Mar 2011 11:15:10 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 2DC903A6A04; Thu, 17 Mar 2011 11:15:10 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 17 Mar 2011 14:16:37 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Thu, 17 Mar 2011 14:16:37 -0400 From: Victor Pascual To: "Worley, Dale R (Dale)" , "Parthasarathi R (partr)" , "Cullen Jennings (fluffy)" , "Mike Hammer (hmmr)" , Hadriel Kaplan , "keith.drage@alcatel-lucent.com" , "john.elwell@siemens-enterprise.com" , "mary.ietf.barnes@gmail.com" , "Paul Kyzivat (pkyzivat)" , "paulej@packetizer.com" , "rjsparks@nostrum.com" , "spromano@unina.it" , "Thierry.Bessis@alcatel-lucent.com" , "vkg@bell-labs.com" Date: Thu, 17 Mar 2011 14:16:37 -0400 Thread-Topic: Bar BOF request for SIP Load balancing & (media) overload handling Thread-Index: AcvkNQDWIeXRlo1yRRq3Yg+LUWi3ZAAgh/mhAAZHhQA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAgAAAUAAAAFU X-Mailman-Approved-At: Thu, 17 Mar 2011 14:44:34 -0700 Cc: "dispatch@ietf.org" , "sip-overload@ietf.org" Subject: Re: [sip-overload] Bar BOF request for SIP Load balancing & (media) overload handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 18:15:11 -0000 Count me in -Victor >-----Original Message----- >From: Worley, Dale R (Dale) [mailto:dworley@avaya.com] >Sent: Thursday, March 17, 2011 4:22 PM >To: Parthasarathi R (partr); Cullen Jennings (fluffy); Mike Hammer >(hmmr); Hadriel Kaplan; keith.drage@alcatel-lucent.com; >john.elwell@siemens-enterprise.com; mary.ietf.barnes@gmail.com; Paul >Kyzivat (pkyzivat); paulej@packetizer.com; rjsparks@nostrum.com; >spromano@unina.it; Thierry.Bessis@alcatel-lucent.com; vkg@bell-labs.com; >Victor Pascual >Cc: dispatch@ietf.org; sip-overload@ietf.org >Subject: RE: Bar BOF request for SIP Load balancing & (media) overload >handling > >________________________________________ >From: Parthasarathi R (partr) [partr@cisco.com] > >Please let me about others interest and opinion to have Bar BOF for SIP >Load balancing & overload handling during IETF-80. >________________________________________ > >Clearly, this is a subject that needs study within the IETF, so the bar >BOF is a very good idea. >(I'll be at IETF Prague.) > >Dale From gonzalo.camarillo@ericsson.com Thu Mar 24 08:44:28 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D40528C0DE; Thu, 24 Mar 2011 08:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.601 X-Spam-Level: X-Spam-Status: No, score=-106.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uO1FC8rZsgVD; Thu, 24 Mar 2011 08:44:27 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 1903728C0D0; Thu, 24 Mar 2011 08:44:26 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-a7-4d8b673832d9 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 26.58.09202.8376B8D4; Thu, 24 Mar 2011 16:46:00 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Thu, 24 Mar 2011 16:46:00 +0100 Received: from [131.160.126.144] (rvi2-126-144.lmf.ericsson.se [131.160.126.144]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0E5A2245F; Thu, 24 Mar 2011 17:46:00 +0200 (EET) Message-ID: <4D8B6737.8050200@ericsson.com> Date: Thu, 24 Mar 2011 17:45:59 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Paul E. Jones" References: <4D8200AC.5070307@packetizer.com> In-Reply-To: <4D8200AC.5070307@packetizer.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Thu, 24 Mar 2011 08:56:18 -0700 Cc: "dworley@avaya.com" , "vpascual@acmepacket.com" , "sip-overload@ietf.org" , "spromano@unina.it" , "keith.drage@alcatel-lucent.com" , "HKaplan@acmepacket.com" , "dispatch@ietf.org" , "Thierry.Bessis@alcatel-lucent.com" , "Mike Hammer \(hmmr\)" Subject: Re: [sip-overload] Bar BOF request for SIP Load balancing & (media) overload handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 15:44:28 -0000 Hi, thanks for the feedback. We will address that issue in the next revision of the draft ;o) Jokes aside, one of the main points of the draft is that the term "bar BOF" confuses many people (specially because it contains the word "BOF" and people end up confusing bar BOFs with actual BOFs). So, we recommend to call them "side meetings" instead. Cheers, Gonzalo On 17/03/2011 2:38 PM, Paul E. Jones wrote: > This is not entirely helpful. It does not go into explaining what kind > or how much beer Partha is going to be required to buy everyone who > attends ;-) > > On 3/16/2011 10:18 PM, Cullen Jennings wrote: >> Just as FYI ... if you have not seen it, you might want to have a read of >> http://tools.ietf.org/html/draft-eggert-successful-bar-bof >> >> >> On Mar 16, 2011, at 6:44 PM, Parthasarathi R (partr) wrote: >> >>> Hi all, >>> >>> There is lot of discussion about SIP load balancing and overload handling in Dispatch alias. I wish to have discussion about SIP Load balancing& (media) overload handling at IETF-80 Prague. I guess that Bar BOF is the idle way to start the discussion about this topic to common understanding and identify the way to move forward. Please suggest me in case any other mechanism exists in IETF. >>> >>> I have included the folks who has shown the interest in this topic as part of SIP Load balancing& overload handling, dispatch WG chairs, CCed to Dispatch and SoC WG alias. AFAIK, the couple of drafts are related to this problem: >>> >>> draft-bessis-dispatch-adaptive-load-balancing-00 >>> draft-partha-dispatch-sip-media-overload-control-00.txt >>> draft-jones-sip-overload-sce-00 >>> draft-partha-dispatch-resource-availability-00 >>> draft-sparks-sipping-load-00 >>> >>> Please let me about others interest and opinion to have Bar BOF for SIP Load balancing& overload handling during IETF-80. >>> >>> Thanks >>> Partha > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > From jgunn6@csc.com Mon Mar 28 13:42:59 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1DD228C106 for ; Mon, 28 Mar 2011 13:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[AWL=-2.125, BAYES_00=-2.599, FRT_MEETING=2.697, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4la-2fQBJgML for ; Mon, 28 Mar 2011 13:42:58 -0700 (PDT) Received: from mail145.messagelabs.com (mail145.messagelabs.com [216.82.242.163]) by core3.amsl.com (Postfix) with ESMTP id C715E3A6902 for ; Mon, 28 Mar 2011 13:42:57 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-12.tower-145.messagelabs.com!1301345072!29792169!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 26847 invoked from network); 28 Mar 2011 20:44:32 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-12.tower-145.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Mar 2011 20:44:32 -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.3.3mp) with ESMTP id p2SKiVBf016651 for ; Mon, 28 Mar 2011 16:44:31 -0400 Importance: Normal X-Priority: 3 (Normal) Sensitivity: In-Reply-To: <4D52AE9B.4070901@bell-labs.com> References: <4D3876BF.9050009@bell-labs.com> <9ECCF01B52E7AB408A7EB85352642141027CFAFE@ftrdmel0.rd.francetelecom.fr> <4D503A57.6070206@bell-labs.com> <9ECCF01B52E7AB408A7EB8535264214102810BAC@ftrdmel0.rd.francetelecom.fr> <4D51BF4B.5070500@alcatel-lucent.com>, <4D52AE9B.4070901@bell-labs.com> MIME-Version: 1.0 From: Janet P Gunn To: "Vijay K. Gurbani" Message-ID: Date: Mon, 28 Mar 2011 16:44:29 -0400 X-Mailer: Lotus Domino Web Server Release 8.5.2FP1 November 29, 2010 X-MIMETrack: Serialize by Notes Server on AMER-ML22/SRV/CSC(Release 8.5.2FP1|November 29, 2010) at 03/28/2011 16:44:29, Serialize complete at 03/28/2011 16:44:29, Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP1 HF29|January 09, 2011) at 03/28/2011 04:43:27 PM MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sip-overload@ietf.org Subject: [sip-overload] Comments on draft-ietf-soc-overload-control-02 - was Re: draft-ietf-soc-overload-control-01 submitted X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 20:43:00 -0000

My apologies for the lateness of these comnments.  Other work,= and procrastination, were made worse by a major crash of my laptop.

= But here are my comments on Appendix B of draft-ietf-soc-overload-control-0= 2.

Assuming my temporary loaner laptop is up to the job, I'll be part= icipating via jabber and audiostreaming on Tuesday.

Janet

C= omments on draft-ietf-soc-overload-control-02.txt Appendix B RFC5390 requir= ements

=  

Meeting Re= q 1

Change

=E2=80=9Cby requesting the ups= tream clients to reduce traffic destined downstream=E2=80=9D

To

=E2=80=9Cby requesting the upstream clients to red= uce traffic destined downstream only s much as is needed to prevent overloa= ding the downstream nodes=E2=80=9D

Meeting Req 2

But, the upstream node is permitted to send the rejected messages o= other nodes, possibly overloading them.

Meeting REQ 4

But if an UPSTREAM node does not support this mechanism, it m= ay generate more downstream traffic than has been throttles by the conformi= ng nodes, and the downstreamnode9s0 will continue to be overloaded.<= /P>

 

Meeeting REQ 6

Yes it is applicable.  The = point is not whether it is a =E2=80=9Cnew header=E2=80=9D or a =E2=80=9Cpar= t of an existing header=E2=80=9D  but whether it is ambiguous, as opposed to being uniquely used for ove= rload.  In this case, the hea= der defined in this draft is ONLY used to signal overload information, so i= t satisfies REQ 6.

Meeting REQ 8

Change

=E2=80=9Cwill not retry the request on another elemen= t=E2=80=9D  

to

<= FONT face=3DCalibri size=3D3>=E2=80=9Cwill not retry the request to another= element it knows to be overloaded=E2=80=9D

 

Meeting REQ  9

Change =E2=80=9Cto another element=E2=80=9D<= /P>

To

= =E2=80=9Cto another element that has not indi= cated that it is overloaded=E2=80=9D

 <= /o:p>

Meeting REQ  = 10

Should be =E2=80=9CNo=E2=80=9D.  There is no limit on the number of upstream clients= , but the upstream clients MUST be enumerated (listed).

M= eeting REQ 12

Add =E2=80=9Cas long as the domains themselv= es agree to honor the signals=E2=80=9D (or something similar- technology OK= , business policies may not be OK)

Meeting REQ 14

I don=E2=80=99t think the text here addresses the Requirement-  I do not think that this mechan= ism, on its own, mitigates the =E2=80=9Cavalanche restart=E2=80=9D problem.=

Meeting REQ 16

It is not clear to me w= hy being in the Via header =E2=80=9Cminimizes overhead=E2=80=9D.

=

Meeting REQ 17

If there is NO =E2=80=9Cconfidential= and authenticated channel=E2=80=9D, then this mechanism CAN be used to DDo= S.

Meeting REQ 18

I would say =E2=80=9Cpa= rtial=E2=80=9D, as it leaves it to local policy.  The mechanism ITSELF does not address which messages t= o drop.

Meeting REQ 20.

I think this shou= ld be NO.  An upstream node t= hat does not implement this mechanism WILL receive a significant measure of= extra benefit.

Meeting REQ 23

Since it s= till =E2=80=9Cdepends on the type of load balancer=E2=80=9D, I think this s= hould be =E2=80=9Cpartial=E2=80=9D.



This is a PRIVATE message. If you are not the intended rec= ipient, please delete without copying and kindly advise us by e-mail of the= mistake in delivery.
NOTE: Regardless of content, this e-mail shall no= t operate to bind CSC to any order or other contract unless pursuant to exp= licit written agreement or government initiative expressly permitting the u= se of e-mail for such purpose.


-----sip-overload-bounces@ietf.org wrote: -----

To: sip-overload@ietf.orgFrom: "Vijay K. Gurbani" <vkg@bell-labs.com>
Sent by: sip-overlo= ad-bounces@ietf.org
Date: 02/09/2011 10:11AM
Subject: Re: [sip-overlo= ad] draft-ietf-soc-overload-control-01 submitted

On 02/08/2011 04:10 PM= , Volker Hilt wrote:
> Vijay, Bruno, following the discussion above -= I believe that REQ-23 can
> in fact be met for load balancers that a= re not SIP aware. Of course,
> there is always a way to build a syste= m that does not work. But the key
> point is that this requirement ca= n be met with the correct design.
>
> My suggestion would be to= document these approaches in the draft as this
> will be very releva= nt for implementers.
>
> I think with this documentation, a "Ye= s" to REQ-23 is appropriate.

OK, this is more work for me then simpl= y changing a "Yes" to "Partial".
But, I will go ahead and do so.  I= f we need more discussion around
this, we should hold it now before I up= date the draft and summarize
the current discussion ...

Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent=
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email= : vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web: &n= bsp; http://ec= t.bell-labs.com/who/vkg/
=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
=
= = From salvatore.loreto@ericsson.com Tue Mar 29 01:22:06 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38D853A6A3A for ; Tue, 29 Mar 2011 01:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.595 X-Spam-Level: X-Spam-Status: No, score=-106.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbqTsbsP0A3X for ; Tue, 29 Mar 2011 01:22:04 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 224D73A68C7 for ; Tue, 29 Mar 2011 01:22:03 -0700 (PDT) X-AuditID: c1b4fb3d-b7bbbae000005311-36-4d91970d2923 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C0.71.21265.D07919D4; Tue, 29 Mar 2011 10:23:41 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 29 Mar 2011 10:23:40 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CFF71236E; Tue, 29 Mar 2011 11:23:40 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9B98D50991; Tue, 29 Mar 2011 11:23:40 +0300 (EEST) Received: from dhcp-1324.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 43CEB50436; Tue, 29 Mar 2011 11:23:40 +0300 (EEST) Message-ID: <4D91970C.3040400@ericsson.com> Date: Tue, 29 Mar 2011 10:23:40 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 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] IETF 80 SoC WG session X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 08:22:06 -0000 Hi there, The IETF 80 SOC WG session will held in Grand Ballroom at 15:20 today (Tuesday March 29, 2011). The agenda has been posted to: http://tools.ietf.org/wg/soc/agenda?item=agenda80.html The audio stream is at: http://ietf80streaming.dnsalias.net/ietf/ietf805.m3u The Jabber room is xmpp:soc@jabber.ietf.org?join you can find the slides for the today meeting here: https://datatracker.ietf.org/meeting/80/materials.html -- Salvatore Loreto www.sloreto.com From keith.drage@alcatel-lucent.com Tue Mar 29 06:56:40 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1CD93A6A3E for ; Tue, 29 Mar 2011 06:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.998 X-Spam-Level: X-Spam-Status: No, score=-105.998 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxAxd8pLH12H for ; Tue, 29 Mar 2011 06:56:39 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 44E293A6A3C for ; Tue, 29 Mar 2011 06:56:39 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p2TDsSoA012987 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 29 Mar 2011 15:58:15 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 29 Mar 2011 15:58:07 +0200 From: "DRAGE, Keith (Keith)" To: "sip-overload@ietf.org" Date: Tue, 29 Mar 2011 15:58:06 +0200 Thread-Topic: draft-ietf-soc-overload-control-02 Thread-Index: AcvuGVQm5sSS5QmxS+6HVpIltqJ6+Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: [sip-overload] draft-ietf-soc-overload-control-02 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 13:56:40 -0000 OK so you asked me to look at section 12 in the soc meeting and I have done= so. 12. 100-Trying provisional response and overload control parameters The overload control information sent from a SIP server to a client is transported in the responses. While implementations can insert overload control information in any response, special attention should be accorded to overload control information transported in a 100-Trying response. Traditionally, the 100-Trying response has been used in SIP to quench retransmissions. In some implementations, the 100-Trying message may not be generated by the transaction user (TU) nor consumed by the TU. In these implementations, the 100-Trying response is generated at the transaction layer and sent to the upstream SIP client. At the receiving SIP client, the 100-Trying is consumed at the transaction layer by inhibiting the retransmission of the corresponding request. Consequently, implementations that insert overload control information in the 100-Trying cannot assume that the upstream SIP client passed the overload control information in the 100-Trying to their corresponding TU. For this reason, implementations that insert overload control information in the 100-Trying MUST re-insert the same (or updated) overload control information in the first non-100 response being sent to the upstream SIP client. My understanding for allowing this is simplicity in the sender (to treat al= l 100 and 1xx in a similar manner at the sender), rather than expectation t= hat the receiver will receive it. I think this point needs to be made clear= er. Regards Keith From michael@voip.co.uk Tue Mar 29 07:01:48 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACB0E3A690F for ; Tue, 29 Mar 2011 07:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF-2xhBqxznz for ; Tue, 29 Mar 2011 07:01:48 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by core3.amsl.com (Postfix) with SMTP id A51D33A693E for ; Tue, 29 Mar 2011 07:01:47 -0700 (PDT) Received: from source ([209.85.212.52]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKTZHmrSS8y7ZdQ6Qkz5P+nnrAYdzcbOiz@postini.com; Tue, 29 Mar 2011 07:03:26 PDT Received: by mail-vw0-f52.google.com with SMTP id 16so200914vws.11 for ; Tue, 29 Mar 2011 07:03:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.0.37 with SMTP id 5mr807493vdb.269.1301407405250; Tue, 29 Mar 2011 07:03:25 -0700 (PDT) Received: by 10.52.160.102 with HTTP; Tue, 29 Mar 2011 07:03:25 -0700 (PDT) Date: Tue, 29 Mar 2011 16:03:25 +0200 Message-ID: From: Michael Procter To: sip-overload@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sip-overload] Comment on draft-ietf-soc-overload-control-02 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 14:01:48 -0000 I'm assuming this is a typo/simple omission, but I may be wrong. Section 7 contains: A SIP client maintains the "oc" parameter values received along with the address and port number of the SIP servers from which they were received... Section 8 contains: After selecting a specific SIP server from the Expected Output, the SIP client MUST determine if it already has overload control parameter values for the server chosen from the Expected Output. I was expecting Section 8 to say "for the server and port chosen", not just the server. Is the omission of the port in this check intentional? Or am I conflating 'server' and 'address' incorrectly? Regards, Michael From HKaplan@acmepacket.com Tue Mar 29 09:07:32 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A5B3A6862 for ; Tue, 29 Mar 2011 09:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTAMIL1QB73L for ; Tue, 29 Mar 2011 09:07:31 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 780BB3A6812 for ; Tue, 29 Mar 2011 09:07:31 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 29 Mar 2011 12:09:08 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Tue, 29 Mar 2011 12:09:08 -0400 From: Hadriel Kaplan To: "sip-overload@ietf.org" Date: Tue, 29 Mar 2011 12:09:06 -0400 Thread-Topic: draft-ietf-soc-overload-control-02 and algorithm agility Thread-Index: AcvuK6JBj110eJkuRGSbeMIgPeP2JQ== Message-ID: <9AD888D2-CCED-4C4C-8F21-C3FA209538C3@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Subject: [sip-overload] draft-ietf-soc-overload-control-02 and algorithm agility X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 16:07:32 -0000 Howdy, in today's WG session the new oc-algo mechanism was described, and it was s= tated the WG had agreed to support multiple algorithms, with a pointer to t= his thread: http://www.ietf.org/mail-archive/web/sip-overload/current/msg00436.html I have read that thread, and there were actually few discussions about the = need for multiple algorithms (most of it was about 100 response handling or= how often algorithms would change, not the need for multiple algorithms). 2 people seemed to want to support multiple algorithms, but did not define = what the "other" one would be. So I'm going to try to argue for NOT doing this (at least not right now). = Here's why: 1) Every time we add something optional, interop issues happen. The protoc= ol gets more complicated, there's more to test, more to fail, etc. ISTM th= at a overload control mechanism should be as simple as possible, with the g= reatest probability of success and interop. For me, the bar would have to = pretty darn high to add optionality - there would have to be a really good = reason. 2) Currently, there is only one algorithm: loss. Other algorithms were tes= ted (rate and window), but since the results were effectively the same, it = would seem rather foolish to add support for those other two. So this woul= d have to be a 4th, as yet unknown, algorithm. That's fine, but we don't n= eed to create a param or logic to handle unknown future algorithms *now*. T= hink about it - nothing prevents a future algorithm from adding this oc-alg= o param in a backwards-compatible manner. Ergo, we don't need to do it now= . In fact, since we don't know the future algorithm(s), we have no idea if= they could even use the other params we have. 3) Doing this is not as trivial as the draft currently has it. You cannot = just "negotiate" it by having *only* the client-side send the param again i= n the next request when it wants to re-negotiate it, because the client has= no idea when its next-hop server has rebooted, or the next-hop server's ha= d *its* config changed. If that happens, the server would get a request fo= rm the client without the param, and thus think the client is using loss, e= ven if they previously negotiated some new algo. =20 4) When you're the server-side, you'll now have to keep a negotiated algori= thm setting pre previous hop client. For some server systems that's easy, = but for some servers that's untenable - they don't keep state per previous = hop client. And I believe our charter requires us to support a model of un= known previous-hop clients. -hadriel From jgunn6@csc.com Tue Mar 29 10:57:08 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79073A6931 for ; Tue, 29 Mar 2011 10:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.758 X-Spam-Level: X-Spam-Status: No, score=-4.758 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vx5u5vl1TTqX for ; Tue, 29 Mar 2011 10:57:06 -0700 (PDT) Received: from mail130.messagelabs.com (mail130.messagelabs.com [216.82.250.163]) by core3.amsl.com (Postfix) with ESMTP id 6F5753A68E4 for ; Tue, 29 Mar 2011 10:57:05 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-10.tower-130.messagelabs.com!1301421520!53403407!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 14730 invoked from network); 29 Mar 2011 17:58:41 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-10.tower-130.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Mar 2011 17:58:41 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id p2THwdcr005683 for ; Tue, 29 Mar 2011 13:58:39 -0400 Importance: Normal X-Priority: 3 (Normal) Sensitivity: In-Reply-To: <9AD888D2-CCED-4C4C-8F21-C3FA209538C3@acmepacket.com> References: <9AD888D2-CCED-4C4C-8F21-C3FA209538C3@acmepacket.com> MIME-Version: 1.0 From: Janet P Gunn To: Hadriel Kaplan Message-ID: Date: Tue, 29 Mar 2011 13:58:37 -0400 X-Mailer: Lotus Domino Web Server Release 8.5.2FP1 November 29, 2010 X-MIMETrack: Serialize by Notes Server on AMER-ML22/SRV/CSC(Release 8.5.2FP1|November 29, 2010) at 03/29/2011 13:58:37, Serialize complete at 03/29/2011 13:58:37, Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP1 HF29|January 09, 2011) at 03/29/2011 01:57:34 PM MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-control-02 and algorithm agility X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 17:57:09 -0000
I was one of the people pushing hard for the use of a rate ba= sed algorithm, either as well as or instead of a percentage loss based algo= rithm.
 
 
I know&nbs= p;I discussed this in much greater detail at some point- but I can't find t= he specific message. Maybe it is in the minutes of the interim
&n= bsp;
While both loss based and rate based algorithms work well in= a simulated environment, driven by random processes, there are a number&nb= sp; of highly probable real world scenarios (e.g. highly localized source o= f overload, or rapidly varying overload) in which a loss based algorithm is= either ineffective or unfair.
 
Evidence of the g= reater robusness, fairness, and effectiveness of rate-based network ma= nagement controls is found in the circuit switched PSTN where "Call Gapping= " (rate based) has made the percentage-dropped network management controls = all but obsolete.
 
There are, of course, many dif= ferences between the PSTN and a SIP network.  But this particular case= seems to be a place where we can, and should, learn from the lessons learn= ed in the PSTN.
 
Janet
-----sip-overload-bounces@ietf.org wrote: -----

To: "sip-overload@ietf.org" <s= ip-overload@ietf.org>
From: Hadriel Kaplan <HKaplan@acmepacket.com= >
Sent by: sip-overload-bounces@ietf.org
Date: 03/29/2011 12:09PM<= BR>Subject: [sip-overload] draft-ietf-soc-overload-control-02 and algorithm= agility

Howdy,
in today's WG session the new oc-algo mechanism was = described, and it was stated the WG had agreed to support multiple algorith= ms, with a pointer to this thread:
http://www.ie= tf.org/mail-archive/web/sip-overload/current/msg00436.html

I hav= e read that thread, and there were actually few discussions about the need = for multiple algorithms (most of it was about 100 response handling or how = often algorithms would change, not the need for multiple algorithms).
2 people seemed to want to support multiple algorithms, but did not defin= e what the "other" one would be.

So I'm going to try to argue for NO= T doing this (at least not right now).  Here's why:

1) Every ti= me we add something optional, interop issues happen.  The protocol get= s more complicated, there's more to test, more to fail, etc.  ISTM tha= t a overload control mechanism should be as simple as possible, with the gr= eatest probability of success and interop.  For me, the bar would have= to pretty darn high to add optionality - there would have to be a really g= ood reason.

2) Currently, there is only one algorithm: loss.  O= ther algorithms were tested (rate and window), but since the results were e= ffectively the same, it would seem rather foolish to add support for those = other two.  So this would have to be a 4th, as yet unknown, algorithm.=  That's fine, but we don't need to create a param or logic to handle = unknown future algorithms *now*. Think about it - nothing prevents a future= algorithm from adding this oc-algo param in a backwards-compatible manner.=  Ergo, we don't need to do it now.  In fact, since we don't know= the future algorithm(s), we have no idea if they could even use the other = params we have.

3) Doing this is not as trivial as the draft current= ly has it.  You cannot just "negotiate" it by having *only* the client= -side send the param again in the next request when it wants to re-negotiat= e it, because the client has no idea when its next-hop server has rebooted,= or the next-hop server's had *its* config changed.  If that happens, = the server would get a request form the client without the param, and thus = think the client is using loss, even if they previously negotiated some new= algo.  

4) When you're the server-side, you'll now have to kee= p a negotiated algorithm setting pre previous hop client.  For some se= rver systems that's easy, but for some servers that's untenable - they don'= t keep state per previous hop client.  And I believe our charter requi= res us to support a model of unknown previous-hop clients.

-hadriel<= BR>


=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

<= /FONT>= = From HKaplan@acmepacket.com Tue Mar 29 15:49:14 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA7A3A6AC5 for ; Tue, 29 Mar 2011 15:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.271 X-Spam-Level: X-Spam-Status: No, score=-1.271 tagged_above=-999 required=5 tests=[AWL=-0.777, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+lPUoIlQoQb for ; Tue, 29 Mar 2011 15:49:13 -0700 (PDT) Received: from ETMail2.acmepacket.com (unknown [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id 23C703A6A7B for ; Tue, 29 Mar 2011 15:49:12 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 29 Mar 2011 18:50:49 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Tue, 29 Mar 2011 18:50:49 -0400 From: Hadriel Kaplan To: Janet P Gunn Date: Tue, 29 Mar 2011 18:50:46 -0400 Thread-Topic: [sip-overload] draft-ietf-soc-overload-control-02 and algorithm agility Thread-Index: AcvuY7+t3l2Zm2PLQHeKnfdrXcspuA== Message-ID: <77199F7F-CC15-4113-AAF6-11654FC5C76B@acmepacket.com> References: <9AD888D2-CCED-4C4C-8F21-C3FA209538C3@acmepacket.com> In-Reply-To: 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_77199F7FCC154113AAF611654FC5C76Bacmepacketcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAgAAAUAAAAFT Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-control-02 and algorithm agility X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 22:49:15 -0000 --_000_77199F7FCC154113AAF611654FC5C76Bacmepacketcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable But that to me argues we shouldn't pick the loss-based one to begin with. Either they're all effectively the same, or they're not. As far as I know,= the results of the design-team were they were the same, so the loss based = one was picked just because it's the simplest to implement. If a rate-base= d is instead more effective, even if it's just for "corner cases", then we = should pick that one instead. No? -hadriel On Mar 29, 2011, at 1:58 PM, Janet P Gunn wrote: I was one of the people pushing hard for the use of a rate based algorithm,= either as well as or instead of a percentage loss based algorithm. See, for instance, http://www.ietf.org/mail-archive/web/sip-overload/curren= t/msg00403.html http://www.ietf.org/mail-archive/web/sip-overload/current/msg00411.html I know I discussed this in much greater detail at some point- but I can't f= ind the specific message. Maybe it is in the minutes of the interim While both loss based and rate based algorithms work well in a simulated en= vironment, driven by random processes, there are a number of highly probab= le real world scenarios (e.g. highly localized source of overload, or rapid= ly varying overload) in which a loss based algorithm is either ineffective = or unfair. Evidence of the greater robusness, fairness, and effectiveness of rate-base= d network management controls is found in the circuit switched PSTN where "= Call Gapping" (rate based) has made the percentage-dropped network manageme= nt controls all but obsolete. There are, of course, many differences between the PSTN and a SIP network. = But this particular case seems to be a place where we can, and should, lea= rn from the lessons learned in the PSTN. Janet -----sip-overload-bounces@ietf.org wrote: ----- To: "sip-overload@ietf.org" > From: Hadriel Kaplan = > Sent by: sip-overload-bounces@ietf.org Date: 03/29/2011 12:09PM Subject: [sip-overload] draft-ietf-soc-overload-control-02 and algorithm ag= ility Howdy, in today's WG session the new oc-algo mechanism was described, and it was s= tated the WG had agreed to support multiple algorithms, with a pointer to t= his thread: http://www.ietf.org/mail-archive/web/sip-overload/current/msg00436.html I have read that thread, and there were actually few discussions about the = need for multiple algorithms (most of it was about 100 response handling or= how often algorithms would change, not the need for multiple algorithms). 2 people seemed to want to support multiple algorithms, but did not define = what the "other" one would be. So I'm going to try to argue for NOT doing this (at least not right now). = Here's why: 1) Every time we add something optional, interop issues happen. The protoc= ol gets more complicated, there's more to test, more to fail, etc. ISTM th= at a overload control mechanism should be as simple as possible, with the g= reatest probability of success and interop. For me, the bar would have to = pretty darn high to add optionality - there would have to be a really good = reason. 2) Currently, there is only one algorithm: loss. Other algorithms were tes= ted (rate and window), but since the results were effectively the same, it = would seem rather foolish to add support for those other two. So this woul= d have to be a 4th, as yet unknown, algorithm. That's fine, but we don't n= eed to create a param or logic to handle unknown future algorithms *now*. T= hink about it - nothing prevents a future algorithm from adding this oc-alg= o param in a backwards-compatible manner. Ergo, we don't need to do it now= . In fact, since we don't know the future algorithm(s), we have no idea if= they could even use the other params we have. 3) Doing this is not as trivial as the draft currently has it. You cannot = just "negotiate" it by having *only* the client-side send the param again i= n the next request when it wants to re-negotiate it, because the client has= no idea when its next-hop server has rebooted, or the next-hop server's ha= d *its* config changed. If that happens, the server would get a request fo= rm the client without the param, and thus think the client is using loss, e= ven if they previously negotiated some new algo. 4) When you're the server-side, you'll now have to keep a negotiated algori= thm setting pre previous hop client. For some server systems that's easy, = but for some servers that's untenable - they don't keep state per previous = hop client. And I believe our charter requires us to support a model of un= known previous-hop clients. -hadriel _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload --_000_77199F7FCC154113AAF611654FC5C76Bacmepacketcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

But th= at to me argues we shouldn't pick the loss-based one to begin with.
Either they're all effectively the same, or they're not.  As far as= I know, the results of the design-team were they were the same, so the los= s based one was picked just because it's the simplest to implement.  I= f a rate-based is instead more effective, even if it's just for "corner cas= es", then we should pick that one instead.
No?

-hadriel


On Mar 29, 2011, at 1:58 = PM, Janet P Gunn wrote:


I was one of the people pushing hard for = the use of a rate based algorithm, either as well as or instead of a percen= tage loss based algorithm.
 
See, for instance, http://www.ietf.org/mail-archive/web/sip-overload/c= urrent/msg00403.html
&nb= sp;
I know I discussed this in much greater detail at some p= oint- but I can't find the specific message. Maybe it is in the minutes of = the interim
 
While both loss based and rate based= algorithms work well in a simulated environment, driven by random processe= s, there are a number  of highly probable real world scenarios (e.g. h= ighly localized source of overload, or rapidly varying overload) in which a= loss based algorithm is either ineffective or unfair.
 
Evidence of the greater robusness, fairness, and effectiveness = of rate-based network management controls is found in the circuit switched = PSTN where "Call Gapping" (rate based) has made the percentage-dropped netw= ork management controls all but obsolete.
 
There = are, of course, many differences between the PSTN and a SIP network.  = But this particular case seems to be a place where we can, and should, lear= n from the lessons learned in the PSTN.
 
Janet-----sip-overload-bounces@ietf.org wrote: -----

To: "sip-overload@ietf.org" <sip-overload@ietf.org>
From: Hadriel Kaplan &l= t;HKaplan@acmepacket.com><= br>Sent by: sip-overload-b= ounces@ietf.org
Date: 03/29/2011 12:09PM
Subject: [sip-overload] = draft-ietf-soc-overload-control-02 and algorithm agility

Howdy,
i= n today's WG session the new oc-algo mechanism was described, and it was st= ated the WG had agreed to support multiple algorithms, with a pointer to th= is thread:
http://www.ietf.org/mail-archive/we= b/sip-overload/current/msg00436.html

I have read that thread, an= d there were actually few discussions about the need for multiple algorithm= s (most of it was about 100 response handling or how often algorithms would= change, not the need for multiple algorithms).

2 people seemed to w= ant to support multiple algorithms, but did not define what the "other" one= would be.

So I'm going to try to argue for NOT doing this (at least= not right now).  Here's why:

1) Every time we add something op= tional, interop issues happen.  The protocol gets more complicated, th= ere's more to test, more to fail, etc.  ISTM that a overload control m= echanism should be as simple as possible, with the greatest probability of = success and interop.  For me, the bar would have to pretty darn high t= o add optionality - there would have to be a really good reason.

2) = Currently, there is only one algorithm: loss.  Other algorithms were t= ested (rate and window), but since the results were effectively the same, i= t would seem rather foolish to add support for those other two.  So th= is would have to be a 4th, as yet unknown, algorithm.  That's fine, bu= t we don't need to create a param or logic to handle unknown future algorit= hms *now*. Think about it - nothing prevents a future algorithm from adding= this oc-algo param in a backwards-compatible manner.  Ergo, we don't = need to do it now.  In fact, since we don't know the future algorithm(= s), we have no idea if they could even use the other params we have.
3) Doing this is not as trivial as the draft currently has it.  You c= annot just "negotiate" it by having *only* the client-side send the param a= gain in the next request when it wants to re-negotiate it, because the clie= nt has no idea when its next-hop server has rebooted, or the next-hop serve= r's had *its* config changed.  If that happens, the server would get a= request form the client without the param, and thus think the client is us= ing loss, even if they previously negotiated some new algo.  

4= ) When you're the server-side, you'll now have to keep a negotiated algorit= hm setting pre previous hop client.  For some server systems that's ea= sy, but for some servers that's untenable - they don't keep state per previ= ous hop client.  And I believe our charter requires us to support a mo= del of unknown previous-hop clients.

-hadriel



_______= ________________________________________
sip-overload mailing list
sip-overload@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sip-overload


= --_000_77199F7FCC154113AAF611654FC5C76Bacmepacketcom_-- From jgunn6@csc.com Wed Mar 30 06:29:07 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 181453A6B11 for ; Wed, 30 Mar 2011 06:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.854 X-Spam-Level: X-Spam-Status: No, score=-4.854 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qq5Qd4y5mZSH for ; Wed, 30 Mar 2011 06:29:04 -0700 (PDT) Received: from mail130.messagelabs.com (mail130.messagelabs.com [216.82.250.163]) by core3.amsl.com (Postfix) with ESMTP id 8612A3A6816 for ; Wed, 30 Mar 2011 06:29:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-7.tower-130.messagelabs.com!1301491833!51961009!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 15378 invoked from network); 30 Mar 2011 13:30:34 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-7.tower-130.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Mar 2011 13:30:34 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id p2UDUV85001681 for ; Wed, 30 Mar 2011 09:30:33 -0400 Importance: Normal X-Priority: 3 (Normal) Sensitivity: In-Reply-To: <77199F7F-CC15-4113-AAF6-11654FC5C76B@acmepacket.com> References: <9AD888D2-CCED-4C4C-8F21-C3FA209538C3@acmepacket.com> , <77199F7F-CC15-4113-AAF6-11654FC5C76B@acmepacket.com> MIME-Version: 1.0 From: Janet P Gunn To: Hadriel Kaplan Message-ID: Date: Wed, 30 Mar 2011 09:30:29 -0400 X-Mailer: Lotus Domino Web Server Release 8.5.2FP1 November 29, 2010 X-MIMETrack: Serialize by Notes Server on AMER-ML22/SRV/CSC(Release 8.5.2FP1|November 29, 2010) at 03/30/2011 09:30:29, Serialize complete at 03/30/2011 09:30:30, Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP1 HF29|January 09, 2011) at 03/30/2011 09:29:27 AM MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-control-02 and algorithm agility X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 13:29:07 -0000

That would be my preference (use Rate as the only mechanism). = But there was pushback from the supporters of "loss based", so my fallback= position was "at least give the provider a way to use Rate based when the = provider prefers it."

Janet

Th= is is a PRIVATE message. If you are not the intended recipient, please dele= te without copying and kindly advise us by e-mail of the mistake in deliver= y.
NOTE: Regardless of content, this e-mail shall not operate to bind C= SC to any order or other contract unless pursuant to explicit written agree= ment or government initiative expressly permitting the use of e-mail for su= ch purpose.


-----Hadriel Kap= lan <HKaplan@acmepacket.com> wrote: -----

To: Janet P Gunn/USA/CSC@CSC
Fr= om: Hadriel Kaplan <HKaplan@acmepacket.com>
Date: 03/29/2011 06:50= PM
cc: "sip-overload@ietf.org" <sip-overload@ietf.org>
Subject:= Re: [sip-overload] draft-ietf-soc-overload-control-02 and algorithm agilit= y


But that to me argues we shouldn't pick the lo= ss-based one to begin with.
Either they're all effectively the sa= me, or they're not.  As far as I know, the results of the design-team = were they were the same, so the loss based one was picked just because it's= the simplest to implement.  If a rate-based is instead more effective= , even if it's just for "corner cases", then we should pick that one instea= d.
No?

-hadriel


=
On Mar 29, 2011, at 1:58 PM, Janet P Gunn wrote:


I was on= e of the people pushing hard for the use of a rate based algorithm, either = as well as or instead of a percentage loss based algorithm.
 = ;
 
I know I discussed this i= n much greater detail at some point- but I can't find the specific message.= Maybe it is in the minutes of the interim
 
While= both loss based and rate based algorithms work well in a simulated environ= ment, driven by random processes, there are a number  of highly probab= le real world scenarios (e.g. highly localized source of overload, or rapid= ly varying overload) in which a loss based algorithm is either ineffective = or unfair.
 
Evidence of the greater robusness, fa= irness, and effectiveness of rate-based network management controls is= found in the circuit switched PSTN where "Call Gapping" (rate based) has m= ade the percentage-dropped network management controls all but obsolete.
 
There are, of course, many differences between the= PSTN and a SIP network.  But this particular case seems to be a place= where we can, and should, learn from the lessons learned in the PSTN.
 
Janet
-----sip-overload-bounces= @ietf.org wrote: -----

To: "sip-overload@ietf.org" <sip-overload@ietf.org>
From: Hadriel Kaplan <= ;HKaplan@acmepacke= t.com>
Sent by: sip-overload-bounces@ietf.org
Date: 03/29/2011 12:09P= M
Subject: [sip-overload] draft-ietf-soc-overload-control-02 and algorit= hm agility

Howdy,
in today's WG session the new oc-algo mechanism wa= s described, and it was stated the WG had agreed to support multiple algori= thms, with a pointer to this thread:
http://www.= ietf.org/mail-archive/web/sip-overload/current/msg00436.html

I h= ave read that thread, and there were actually few discussions about the nee= d for multiple algorithms (most of it was about 100 response handling or ho= w often algorithms would change, not the need for multiple algorithms).
=
2 people seemed to want to support multiple algorithms, but did not def= ine what the "other" one would be.

So I'm going to try to argue for = NOT doing this (at least not right now).  Here's why:

1) Every = time we add something optional, interop issues happen.  The protocol g= ets more complicated, there's more to test, more to fail, etc.  ISTM t= hat a overload control mechanism should be as simple as possible, with the = greatest probability of success and interop.  For me, the bar would ha= ve to pretty darn high to add optionality - there would have to be a really= good reason.

2) Currently, there is only one algorithm: loss.  = ;Other algorithms were tested (rate and window), but since the results were= effectively the same, it would seem rather foolish to add support for thos= e other two.  So this would have to be a 4th, as yet unknown, algorith= m.  That's fine, but we don't need to create a param or logic to handl= e unknown future algorithms *now*. Think about it - nothing prevents a futu= re algorithm from adding this oc-algo param in a backwards-compatible manne= r.  Ergo, we don't need to do it now.  In fact, since we don't kn= ow the future algorithm(s), we have no idea if they could even use the othe= r params we have.

3) Doing this is not as trivial as the draft curre= ntly has it.  You cannot just "negotiate" it by having *only* the clie= nt-side send the param again in the next request when it wants to re-negoti= ate it, because the client has no idea when its next-hop server has reboote= d, or the next-hop server's had *its* config changed.  If that happens= , the server would get a request form the client without the param, and thu= s think the client is using loss, even if they previously negotiated some n= ew algo.  

4) When you're the server-side, you'll now have to k= eep a negotiated algorithm setting pre previous hop client.  For some = server systems that's easy, but for some servers that's untenable - they do= n't keep state per previous hop client.  And I believe our charter req= uires us to support a model of unknown previous-hop clients.

-hadrie= l



=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



= = From vkg@bell-labs.com Wed Mar 30 06:44:47 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510E23A6B59 for ; Wed, 30 Mar 2011 06:44:47 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJEP5rkHzY-D for ; Wed, 30 Mar 2011 06:44:46 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 133533A6B57 for ; Wed, 30 Mar 2011 06:44:43 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p2UDkL2S014285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 30 Mar 2011 08:46:21 -0500 (CDT) Received: from shoonya.ih.lucent.com (vkg.lra.lucent.com [135.244.41.21]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p2UDkKaW013447 for ; Wed, 30 Mar 2011 08:46:21 -0500 (CDT) Message-ID: <4D93349D.8060804@bell-labs.com> Date: Wed, 30 Mar 2011 08:48:13 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: sip-overload@ietf.org References: 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 Subject: Re: [sip-overload] draft-ietf-soc-overload-control-02 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 13:44:47 -0000 On 03/29/2011 08:58 AM, DRAGE, Keith (Keith) wrote: > OK so you asked me to look at section 12 in the soc meeting and I > have done so. [...] > My understanding for allowing this is simplicity in the sender (to > treat all 100 and 1xx in a similar manner at the sender), rather than > expectation that the receiver will receive it. I think this point > needs to be made clearer. Keith: Well ... Section 12 considers simplicity in the receiver as well as the sender. The sender of the response does not need to couple TU-provided information (oc) with the response being generated at the transaction layer (100), and on the receiving side, the receiver does not have to provide the oc information from the 100 to the TU. If this is not clear, I will make another stab at this. I have to update Section 12 to incorporate Victor's comment regarding 100rel anyway. So, stay tuned for the next revision. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From bruno.chatras@orange-ftgroup.com Wed Mar 30 23:01:40 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0406828C1F9 for ; Wed, 30 Mar 2011 23:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6q+pR2xFjxEJ for ; Wed, 30 Mar 2011 23:01:34 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id E58803A69AC for ; Wed, 30 Mar 2011 23:01:32 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5CF0E8B8006; Thu, 31 Mar 2011 08:03:42 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 4F51F8B8001; Thu, 31 Mar 2011 08:03:42 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 08:03:10 +0200 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_01CBEF69.4FCA6911" Date: Thu, 31 Mar 2011 08:03:09 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214102B3B14E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip-overload] draft-ietf-soc-overload-control-02 and algorithmagility Thread-Index: Acvu3rBv/inirrcfRF6nlZjJD2HopQAiZwSg References: <9AD888D2-CCED-4C4C-8F21-C3FA209538C3@acmepacket.com>, <77199F7F-CC15-4113-AAF6-11654FC5C76B@acmepacket.com> From: To: , X-OriginalArrivalTime: 31 Mar 2011 06:03:10.0544 (UTC) FILETIME=[5025A500:01CBEF69] Cc: sip-overload@ietf.org Subject: Re: [sip-overload] draft-ietf-soc-overload-control-02 and algorithmagility X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 06:01:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEF69.4FCA6911 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IFJhdGUtYmFzZWQgaXMgbW9yZSBlZmZpY2llbnQgZm9y IGhhbmRsaW5nIG1hc3MgY2FsbGluZyAoZS5nLiB0ZWxldm90aW5nKSBidXQgaXMgYSBiaXQgbW9y ZSBjb21wbGV4IHRvIG9wZXJhdGUgdGhhbiBMb3NzLWJhc2VkLiBDb25zaWRlcmluZyB0aGF0IGZv ciBUZWxldm90aW5nIGFuZCBzaW1pbGFyIHNlcnZpY2VzIHRoZSBmaWx0ZXItYmFzZWQgc29sdXRp b24gKGkuZS4gZHJhZnQtc29jLXNoZW7igKYpICBpcyBwcm9iYWJseSBtb3JlIGFwcHJvcHJpYXRl IGFueXdheSwgSeKAmW0gd29uZGVyaW5nIHdoZXRoZXIgUmF0ZS1iYXNlZCBzaG91bGQgcmVhbGx5 IGJlIHRoZSDigJxtYW5kYXRvcnkgZGVmYXVsdOKAnSBmb3IgdGhlIGZlZWRiYWNrLWJhc2VkIHNv bHV0aW9u4oCmDQoNCkJydW5vDQoNCiANCg0KRGUgOiBzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRl IEphbmV0IFAgR3Vubg0KRW52b3nDqSA6IG1lcmNyZWRpIDMwIG1hcnMgMjAxMSAxNTozMA0Kw4Ag OiBIYWRyaWVsIEthcGxhbg0KQ2MgOiBzaXAtb3ZlcmxvYWRAaWV0Zi5vcmcNCk9iamV0IDogUmU6 IFtzaXAtb3ZlcmxvYWRdIGRyYWZ0LWlldGYtc29jLW92ZXJsb2FkLWNvbnRyb2wtMDIgYW5kIGFs Z29yaXRobWFnaWxpdHkNCg0KIA0KDQpUaGF0IHdvdWxkIGJlIG15IHByZWZlcmVuY2UgKHVzZSBS YXRlIGFzIHRoZSBvbmx5IG1lY2hhbmlzbSkuICBCdXQgdGhlcmUgd2FzIHB1c2hiYWNrIGZyb20g dGhlIHN1cHBvcnRlcnMgb2YgImxvc3MgYmFzZWQiLCBzbyBteSBmYWxsYmFjayBwb3NpdGlvbiB3 YXMgImF0IGxlYXN0IGdpdmUgdGhlIHByb3ZpZGVyIGEgd2F5IHRvIHVzZSBSYXRlIGJhc2VkIHdo ZW4gdGhlIHByb3ZpZGVyIHByZWZlcnMgaXQuIg0KDQpKYW5ldA0KDQpUaGlzIGlzIGEgUFJJVkFU RSBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ug ZGVsZXRlIHdpdGhvdXQgY29weWluZyBhbmQga2luZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2Yg dGhlIG1pc3Rha2UgaW4gZGVsaXZlcnkuIA0KTk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0 aGlzIGUtbWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0byBiaW5kIENTQyB0byBhbnkgb3JkZXIgb3Ig b3RoZXIgY29udHJhY3QgdW5sZXNzIHB1cnN1YW50IHRvIGV4cGxpY2l0IHdyaXR0ZW4gYWdyZWVt ZW50IG9yIGdvdmVybm1lbnQgaW5pdGlhdGl2ZSBleHByZXNzbHkgcGVybWl0dGluZyB0aGUgdXNl IG9mIGUtbWFpbCBmb3Igc3VjaCBwdXJwb3NlLg0KDQogDQoNCi0tLS0tSGFkcmllbCBLYXBsYW4g PEhLYXBsYW5AYWNtZXBhY2tldC5jb20+IHdyb3RlOiAtLS0tLQ0KDQpUbzogSmFuZXQgUCBHdW5u L1VTQS9DU0NAQ1NDDQpGcm9tOiBIYWRyaWVsIEthcGxhbiA8SEthcGxhbkBhY21lcGFja2V0LmNv bT4NCkRhdGU6IDAzLzI5LzIwMTEgMDY6NTBQTQ0KY2M6ICJzaXAtb3ZlcmxvYWRAaWV0Zi5vcmci IDxzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NpcC1vdmVybG9hZF0gZHJh ZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbC0wMiBhbmQgYWxnb3JpdGhtIGFnaWxpdHkNCg0K IA0KDQpCdXQgdGhhdCB0byBtZSBhcmd1ZXMgd2Ugc2hvdWxkbid0IHBpY2sgdGhlIGxvc3MtYmFz ZWQgb25lIHRvIGJlZ2luIHdpdGguDQoNCkVpdGhlciB0aGV5J3JlIGFsbCBlZmZlY3RpdmVseSB0 aGUgc2FtZSwgb3IgdGhleSdyZSBub3QuICBBcyBmYXIgYXMgSSBrbm93LCB0aGUgcmVzdWx0cyBv ZiB0aGUgZGVzaWduLXRlYW0gd2VyZSB0aGV5IHdlcmUgdGhlIHNhbWUsIHNvIHRoZSBsb3NzIGJh c2VkIG9uZSB3YXMgcGlja2VkIGp1c3QgYmVjYXVzZSBpdCdzIHRoZSBzaW1wbGVzdCB0byBpbXBs ZW1lbnQuICBJZiBhIHJhdGUtYmFzZWQgaXMgaW5zdGVhZCBtb3JlIGVmZmVjdGl2ZSwgZXZlbiBp ZiBpdCdzIGp1c3QgZm9yICJjb3JuZXIgY2FzZXMiLCB0aGVuIHdlIHNob3VsZCBwaWNrIHRoYXQg b25lIGluc3RlYWQuDQoNCk5vPw0KDQogDQoNCi1oYWRyaWVsDQoNCiANCg0KIA0KDQpPbiBNYXIg MjksIDIwMTEsIGF0IDE6NTggUE0sIEphbmV0IFAgR3VubiB3cm90ZToNCg0KDQoNCg0KDQogDQoN Ckkgd2FzIG9uZSBvZiB0aGUgcGVvcGxlIHB1c2hpbmcgaGFyZCBmb3IgdGhlIHVzZSBvZiBhIHJh dGUgYmFzZWQgYWxnb3JpdGhtLCBlaXRoZXIgYXMgd2VsbCBhcyBvciBpbnN0ZWFkIG9mIGEgcGVy Y2VudGFnZSBsb3NzIGJhc2VkIGFsZ29yaXRobS4NCg0KIA0KDQpTZWUsIGZvciBpbnN0YW5jZSwg aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcC1vdmVybG9hZC9jdXJyZW50 L21zZzAwNDAzLmh0bWwNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Np cC1vdmVybG9hZC9jdXJyZW50L21zZzAwNDExLmh0bWwNCg0KIA0KDQpJIGtub3cgSSBkaXNjdXNz ZWQgdGhpcyBpbiBtdWNoIGdyZWF0ZXIgZGV0YWlsIGF0IHNvbWUgcG9pbnQtIGJ1dCBJIGNhbid0 IGZpbmQgdGhlIHNwZWNpZmljIG1lc3NhZ2UuIE1heWJlIGl0IGlzIGluIHRoZSBtaW51dGVzIG9m IHRoZSBpbnRlcmltDQoNCiANCg0KV2hpbGUgYm90aCBsb3NzIGJhc2VkIGFuZCByYXRlIGJhc2Vk IGFsZ29yaXRobXMgd29yayB3ZWxsIGluIGEgc2ltdWxhdGVkIGVudmlyb25tZW50LCBkcml2ZW4g YnkgcmFuZG9tIHByb2Nlc3NlcywgdGhlcmUgYXJlIGEgbnVtYmVyICBvZiBoaWdobHkgcHJvYmFi bGUgcmVhbCB3b3JsZCBzY2VuYXJpb3MgKGUuZy4gaGlnaGx5IGxvY2FsaXplZCBzb3VyY2Ugb2Yg b3ZlcmxvYWQsIG9yIHJhcGlkbHkgdmFyeWluZyBvdmVybG9hZCkgaW4gd2hpY2ggYSBsb3NzIGJh c2VkIGFsZ29yaXRobSBpcyBlaXRoZXIgaW5lZmZlY3RpdmUgb3IgdW5mYWlyLg0KDQogDQoNCkV2 aWRlbmNlIG9mIHRoZSBncmVhdGVyIHJvYnVzbmVzcywgZmFpcm5lc3MsIGFuZCBlZmZlY3RpdmVu ZXNzIG9mIHJhdGUtYmFzZWQgbmV0d29yayBtYW5hZ2VtZW50IGNvbnRyb2xzIGlzIGZvdW5kIGlu IHRoZSBjaXJjdWl0IHN3aXRjaGVkIFBTVE4gd2hlcmUgIkNhbGwgR2FwcGluZyIgKHJhdGUgYmFz ZWQpIGhhcyBtYWRlIHRoZSBwZXJjZW50YWdlLWRyb3BwZWQgbmV0d29yayBtYW5hZ2VtZW50IGNv bnRyb2xzIGFsbCBidXQgb2Jzb2xldGUuDQoNCiANCg0KVGhlcmUgYXJlLCBvZiBjb3Vyc2UsIG1h bnkgZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGUgUFNUTiBhbmQgYSBTSVAgbmV0d29yay4gIEJ1dCB0 aGlzIHBhcnRpY3VsYXIgY2FzZSBzZWVtcyB0byBiZSBhIHBsYWNlIHdoZXJlIHdlIGNhbiwgYW5k IHNob3VsZCwgbGVhcm4gZnJvbSB0aGUgbGVzc29ucyBsZWFybmVkIGluIHRoZSBQU1ROLg0KDQog DQoNCkphbmV0DQoNCi0tLS0tc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmcgd3JvdGU6IC0t LS0tDQoNClRvOiAic2lwLW92ZXJsb2FkQGlldGYub3JnIiA8c2lwLW92ZXJsb2FkQGlldGYub3Jn Pg0KRnJvbTogSGFkcmllbCBLYXBsYW4gPEhLYXBsYW5AYWNtZXBhY2tldC5jb20+DQpTZW50IGJ5 OiBzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZw0KRGF0ZTogMDMvMjkvMjAxMSAxMjowOVBN DQpTdWJqZWN0OiBbc2lwLW92ZXJsb2FkXSBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9s LTAyIGFuZCBhbGdvcml0aG0gYWdpbGl0eQ0KDQpIb3dkeSwNCmluIHRvZGF5J3MgV0cgc2Vzc2lv biB0aGUgbmV3IG9jLWFsZ28gbWVjaGFuaXNtIHdhcyBkZXNjcmliZWQsIGFuZCBpdCB3YXMgc3Rh dGVkIHRoZSBXRyBoYWQgYWdyZWVkIHRvIHN1cHBvcnQgbXVsdGlwbGUgYWxnb3JpdGhtcywgd2l0 aCBhIHBvaW50ZXIgdG8gdGhpcyB0aHJlYWQ6DQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvc2lwLW92ZXJsb2FkL2N1cnJlbnQvbXNnMDA0MzYuaHRtbA0KDQpJIGhhdmUgcmVh ZCB0aGF0IHRocmVhZCwgYW5kIHRoZXJlIHdlcmUgYWN0dWFsbHkgZmV3IGRpc2N1c3Npb25zIGFi b3V0IHRoZSBuZWVkIGZvciBtdWx0aXBsZSBhbGdvcml0aG1zIChtb3N0IG9mIGl0IHdhcyBhYm91 dCAxMDAgcmVzcG9uc2UgaGFuZGxpbmcgb3IgaG93IG9mdGVuIGFsZ29yaXRobXMgd291bGQgY2hh bmdlLCBub3QgdGhlIG5lZWQgZm9yIG11bHRpcGxlIGFsZ29yaXRobXMpLg0KDQoyIHBlb3BsZSBz ZWVtZWQgdG8gd2FudCB0byBzdXBwb3J0IG11bHRpcGxlIGFsZ29yaXRobXMsIGJ1dCBkaWQgbm90 IGRlZmluZSB3aGF0IHRoZSAib3RoZXIiIG9uZSB3b3VsZCBiZS4NCg0KU28gSSdtIGdvaW5nIHRv IHRyeSB0byBhcmd1ZSBmb3IgTk9UIGRvaW5nIHRoaXMgKGF0IGxlYXN0IG5vdCByaWdodCBub3cp LiAgSGVyZSdzIHdoeToNCg0KMSkgRXZlcnkgdGltZSB3ZSBhZGQgc29tZXRoaW5nIG9wdGlvbmFs LCBpbnRlcm9wIGlzc3VlcyBoYXBwZW4uICBUaGUgcHJvdG9jb2wgZ2V0cyBtb3JlIGNvbXBsaWNh dGVkLCB0aGVyZSdzIG1vcmUgdG8gdGVzdCwgbW9yZSB0byBmYWlsLCBldGMuICBJU1RNIHRoYXQg YSBvdmVybG9hZCBjb250cm9sIG1lY2hhbmlzbSBzaG91bGQgYmUgYXMgc2ltcGxlIGFzIHBvc3Np YmxlLCB3aXRoIHRoZSBncmVhdGVzdCBwcm9iYWJpbGl0eSBvZiBzdWNjZXNzIGFuZCBpbnRlcm9w LiAgRm9yIG1lLCB0aGUgYmFyIHdvdWxkIGhhdmUgdG8gcHJldHR5IGRhcm4gaGlnaCB0byBhZGQg b3B0aW9uYWxpdHkgLSB0aGVyZSB3b3VsZCBoYXZlIHRvIGJlIGEgcmVhbGx5IGdvb2QgcmVhc29u Lg0KDQoyKSBDdXJyZW50bHksIHRoZXJlIGlzIG9ubHkgb25lIGFsZ29yaXRobTogbG9zcy4gIE90 aGVyIGFsZ29yaXRobXMgd2VyZSB0ZXN0ZWQgKHJhdGUgYW5kIHdpbmRvdyksIGJ1dCBzaW5jZSB0 aGUgcmVzdWx0cyB3ZXJlIGVmZmVjdGl2ZWx5IHRoZSBzYW1lLCBpdCB3b3VsZCBzZWVtIHJhdGhl ciBmb29saXNoIHRvIGFkZCBzdXBwb3J0IGZvciB0aG9zZSBvdGhlciB0d28uICBTbyB0aGlzIHdv dWxkIGhhdmUgdG8gYmUgYSA0dGgsIGFzIHlldCB1bmtub3duLCBhbGdvcml0aG0uICBUaGF0J3Mg ZmluZSwgYnV0IHdlIGRvbid0IG5lZWQgdG8gY3JlYXRlIGEgcGFyYW0gb3IgbG9naWMgdG8gaGFu ZGxlIHVua25vd24gZnV0dXJlIGFsZ29yaXRobXMgKm5vdyouIFRoaW5rIGFib3V0IGl0IC0gbm90 aGluZyBwcmV2ZW50cyBhIGZ1dHVyZSBhbGdvcml0aG0gZnJvbSBhZGRpbmcgdGhpcyBvYy1hbGdv IHBhcmFtIGluIGEgYmFja3dhcmRzLWNvbXBhdGlibGUgbWFubmVyLiAgRXJnbywgd2UgZG9uJ3Qg bmVlZCB0byBkbyBpdCBub3cuICBJbiBmYWN0LCBzaW5jZSB3ZSBkb24ndCBrbm93IHRoZSBmdXR1 cmUgYWxnb3JpdGhtKHMpLCB3ZSBoYXZlIG5vIGlkZWEgaWYgdGhleSBjb3VsZCBldmVuIHVzZSB0 aGUgb3RoZXIgcGFyYW1zIHdlIGhhdmUuDQoNCjMpIERvaW5nIHRoaXMgaXMgbm90IGFzIHRyaXZp YWwgYXMgdGhlIGRyYWZ0IGN1cnJlbnRseSBoYXMgaXQuICBZb3UgY2Fubm90IGp1c3QgIm5lZ290 aWF0ZSIgaXQgYnkgaGF2aW5nICpvbmx5KiB0aGUgY2xpZW50LXNpZGUgc2VuZCB0aGUgcGFyYW0g YWdhaW4gaW4gdGhlIG5leHQgcmVxdWVzdCB3aGVuIGl0IHdhbnRzIHRvIHJlLW5lZ290aWF0ZSBp dCwgYmVjYXVzZSB0aGUgY2xpZW50IGhhcyBubyBpZGVhIHdoZW4gaXRzIG5leHQtaG9wIHNlcnZl ciBoYXMgcmVib290ZWQsIG9yIHRoZSBuZXh0LWhvcCBzZXJ2ZXIncyBoYWQgKml0cyogY29uZmln IGNoYW5nZWQuICBJZiB0aGF0IGhhcHBlbnMsIHRoZSBzZXJ2ZXIgd291bGQgZ2V0IGEgcmVxdWVz dCBmb3JtIHRoZSBjbGllbnQgd2l0aG91dCB0aGUgcGFyYW0sIGFuZCB0aHVzIHRoaW5rIHRoZSBj bGllbnQgaXMgdXNpbmcgbG9zcywgZXZlbiBpZiB0aGV5IHByZXZpb3VzbHkgbmVnb3RpYXRlZCBz b21lIG5ldyBhbGdvLiAgDQoNCjQpIFdoZW4geW91J3JlIHRoZSBzZXJ2ZXItc2lkZSwgeW91J2xs IG5vdyBoYXZlIHRvIGtlZXAgYSBuZWdvdGlhdGVkIGFsZ29yaXRobSBzZXR0aW5nIHByZSBwcmV2 aW91cyBob3AgY2xpZW50LiAgRm9yIHNvbWUgc2VydmVyIHN5c3RlbXMgdGhhdCdzIGVhc3ksIGJ1 dCBmb3Igc29tZSBzZXJ2ZXJzIHRoYXQncyB1bnRlbmFibGUgLSB0aGV5IGRvbid0IGtlZXAgc3Rh dGUgcGVyIHByZXZpb3VzIGhvcCBjbGllbnQuICBBbmQgSSBiZWxpZXZlIG91ciBjaGFydGVyIHJl cXVpcmVzIHVzIHRvIHN1cHBvcnQgYSBtb2RlbCBvZiB1bmtub3duIHByZXZpb3VzLWhvcCBjbGll bnRzLg0KDQotaGFkcmllbA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnNpcC1vdmVybG9hZCBtYWlsaW5nIGxpc3QNCnNpcC1vdmVybG9hZEBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXAtb3Zlcmxv YWQNCg0KIA0KDQogDQoNCiANCg0K ------_=_NextPart_001_01CBEF69.4FCA6911 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRl bnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1H ZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0K PHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9 DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3 MC44NXB0O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4N CjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCg0KPGJvZHkgbGFuZz1GUiBsaW5rPWJsdWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2IGNs YXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K Y29sb3I6IzFGNDk3RCc+TXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IFJhdGUtYmFzZWQgaXMgbW9y ZSBlZmZpY2llbnQgZm9yIGhhbmRsaW5nDQptYXNzIGNhbGxpbmcgKGUuZy4gdGVsZXZvdGluZykg YnV0IGlzIGEgYml0IG1vcmUgY29tcGxleCB0byBvcGVyYXRlIHRoYW4NCkxvc3MtYmFzZWQuIENv bnNpZGVyaW5nIHRoYXQgZm9yIFRlbGV2b3RpbmcgYW5kIHNpbWlsYXIgc2VydmljZXMgdGhlIGZp bHRlci1iYXNlZA0Kc29sdXRpb24gKGkuZS4gZHJhZnQtc29jLXNoZW7igKYpIMKgaXMgcHJvYmFi bHkgbW9yZSBhcHByb3ByaWF0ZSBhbnl3YXksIEnigJltDQp3b25kZXJpbmcgd2hldGhlciBSYXRl LWJhc2VkIHNob3VsZCByZWFsbHkgYmUgdGhlIOKAnG1hbmRhdG9yeSBkZWZhdWx04oCdIGZvciB0 aGUNCmZlZWRiYWNrLWJhc2VkIHNvbHV0aW9u4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+QnJ1 bm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoN CjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCc+DQoNCjxkaXY+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtJz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RGUmbmJzcDs6PC9zcGFuPjwv Yj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz4gc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmcNClttYWlsdG86c2lwLW92 ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmddIDxiPkRlIGxhIHBhcnQgZGU8L2I+IEphbmV0IFAgR3Vu bjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSAzMCBtYXJzIDIwMTEgMTU6MzA8 YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEhhZHJpZWwgS2FwbGFuPGJyPg0KPGI+Q2MmbmJzcDs6PC9i PiBzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbc2lw LW92ZXJsb2FkXSBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sLTAyIGFuZA0KYWxnb3Jp dGhtYWdpbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiInPlRo YXQgd291bGQNCmJlIG15IHByZWZlcmVuY2UgKHVzZSBSYXRlIGFzIHRoZSBvbmx5IG1lY2hhbmlz bSkuJm5ic3A7IEJ1dCB0aGVyZSB3YXMgcHVzaGJhY2sNCmZyb20gdGhlIHN1cHBvcnRlcnMgb2Yg JnF1b3Q7bG9zcyBiYXNlZCZxdW90Oywgc28gbXkgZmFsbGJhY2sgcG9zaXRpb24gd2FzDQomcXVv dDthdCBsZWFzdCBnaXZlIHRoZSBwcm92aWRlciBhIHdheSB0byB1c2UgUmF0ZSBiYXNlZCB3aGVu IHRoZSBwcm92aWRlcg0KcHJlZmVycyBpdC4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwi c2Fucy1zZXJpZiInPkphbmV0PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNp emU6Ny41cHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIic+VGhpcyBpcw0KYSBQ UklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs ZWFzZSBkZWxldGUgd2l0aG91dA0KY29weWluZyBhbmQga2luZGx5IGFkdmlzZSB1cyBieSBlLW1h aWwgb2YgdGhlIG1pc3Rha2UgaW4gZGVsaXZlcnkuIDxicj4NCk5PVEU6IFJlZ2FyZGxlc3Mgb2Yg Y29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8gYmluZCBDU0MgdG8gYW55 DQpvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgd3Jp dHRlbiBhZ3JlZW1lbnQgb3INCmdvdmVybm1lbnQgaW5pdGlhdGl2ZSBleHByZXNzbHkgcGVybWl0 dGluZyB0aGUgdXNlIG9mIGUtbWFpbCBmb3Igc3VjaCBwdXJwb3NlLjwvc3Bhbj48c3Bhbg0Kc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIic+ PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNl cmlmIic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOiM5 OTAwOTknPi0tLS0tSGFkcmllbCBLYXBsYW4NCiZsdDtIS2FwbGFuQGFjbWVwYWNrZXQuY29tJmd0 OyB3cm90ZTogLS0tLS08L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250 LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlm Iic+VG86IEphbmV0IFAgR3Vubi9VU0EvQ1NDQENTQzxicj4NCkZyb206IEhhZHJpZWwgS2FwbGFu ICZsdDtIS2FwbGFuQGFjbWVwYWNrZXQuY29tJmd0Ozxicj4NCkRhdGU6IDAzLzI5LzIwMTEgMDY6 NTBQTTxicj4NCmNjOiAmcXVvdDtzaXAtb3ZlcmxvYWRAaWV0Zi5vcmcmcXVvdDsgJmx0O3NpcC1v dmVybG9hZEBpZXRmLm9yZyZndDs8YnI+DQpTdWJqZWN0OiBSZTogW3NpcC1vdmVybG9hZF0gZHJh ZnQtaWV0Zi1zb2Mtb3ZlcmxvYWQtY29udHJvbC0wMiBhbmQgYWxnb3JpdGhtDQphZ2lsaXR5PG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlm Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJWZXJkYW5hIiwic2Fucy1zZXJpZiInPkJ1dA0KdGhhdCB0byBtZSBhcmd1ZXMgd2Ugc2hvdWxk bid0IHBpY2sgdGhlIGxvc3MtYmFzZWQgb25lIHRvIGJlZ2luIHdpdGguPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiIn PkVpdGhlcg0KdGhleSdyZSBhbGwgZWZmZWN0aXZlbHkgdGhlIHNhbWUsIG9yIHRoZXkncmUgbm90 LiAmbmJzcDtBcyBmYXIgYXMgSSBrbm93LCB0aGUNCnJlc3VsdHMgb2YgdGhlIGRlc2lnbi10ZWFt IHdlcmUgdGhleSB3ZXJlIHRoZSBzYW1lLCBzbyB0aGUgbG9zcyBiYXNlZCBvbmUgd2FzDQpwaWNr ZWQganVzdCBiZWNhdXNlIGl0J3MgdGhlIHNpbXBsZXN0IHRvIGltcGxlbWVudC4gJm5ic3A7SWYg YSByYXRlLWJhc2VkIGlzDQppbnN0ZWFkIG1vcmUgZWZmZWN0aXZlLCBldmVuIGlmIGl0J3MganVz dCBmb3IgJnF1b3Q7Y29ybmVyIGNhc2VzJnF1b3Q7LCB0aGVuIHdlDQpzaG91bGQgcGljayB0aGF0 IG9uZSBpbnN0ZWFkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiJz5Obz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIic+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwi c2Fucy1zZXJpZiInPi1oYWRyaWVsPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0K PGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIs InNhbnMtc2VyaWYiJz5Pbg0KTWFyIDI5LCAyMDExLCBhdCAxOjU4IFBNLCBKYW5ldCBQIEd1bm4g d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwi c2Fucy1zZXJpZiInPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJW ZXJkYW5hIiwic2Fucy1zZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiInPkkNCndhcyBvbmUgb2YgdGhlIHBlb3Bs ZSBwdXNoaW5nIGhhcmQgZm9yIHRoZSB1c2Ugb2YgYSByYXRlIGJhc2VkIGFsZ29yaXRobSwNCmVp dGhlciBhcyB3ZWxsIGFzIG9yIGluc3RlYWQgb2YgYSBwZXJjZW50YWdlIGxvc3MgYmFzZWQgYWxn b3JpdGhtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi VmVyZGFuYSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwv ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIic+U2VlLA0KZm9yIGlu c3RhbmNlLCA8YQ0KaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Np cC1vdmVybG9hZC9jdXJyZW50L21zZzAwNDAzLmh0bWwiDQp0YXJnZXQ9Ymxhbms+aHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcC1vdmVybG9hZC9jdXJyZW50L21zZzAwNDAz Lmh0bWw8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJWZXJkYW5hIiwic2Fucy1zZXJpZiInPjxhDQpocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvc2lwLW92ZXJsb2FkL2N1cnJlbnQvbXNnMDA0MTEuaHRtbCINCnRhcmdl dD1ibGFuaz5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwLW92ZXJsb2Fk L2N1cnJlbnQvbXNnMDA0MTEuaHRtbDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2 Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1z ZXJpZiInPkkNCmtub3cmbmJzcDtJIGRpc2N1c3NlZCB0aGlzIGluIG11Y2ggZ3JlYXRlciBkZXRh aWwgYXQgc29tZSBwb2ludC0gYnV0IEkgY2FuJ3QNCmZpbmQgdGhlIHNwZWNpZmljIG1lc3NhZ2Uu IE1heWJlIGl0IGlzIGluIHRoZSBtaW51dGVzIG9mIHRoZSBpbnRlcmltPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiIn PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi VmVyZGFuYSIsInNhbnMtc2VyaWYiJz5XaGlsZQ0KYm90aCBsb3NzIGJhc2VkIGFuZCByYXRlIGJh c2VkIGFsZ29yaXRobXMgd29yayB3ZWxsIGluIGEgc2ltdWxhdGVkIGVudmlyb25tZW50LA0KZHJp dmVuIGJ5IHJhbmRvbSBwcm9jZXNzZXMsIHRoZXJlIGFyZSBhIG51bWJlciZuYnNwOyBvZiBoaWdo bHkgcHJvYmFibGUgcmVhbA0Kd29ybGQgc2NlbmFyaW9zIChlLmcuIGhpZ2hseSBsb2NhbGl6ZWQg c291cmNlIG9mIG92ZXJsb2FkLCBvciByYXBpZGx5IHZhcnlpbmcNCm92ZXJsb2FkKSBpbiB3aGlj aCBhIGxvc3MgYmFzZWQgYWxnb3JpdGhtIGlzIGVpdGhlciBpbmVmZmVjdGl2ZSBvciB1bmZhaXIu PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5h Iiwic2Fucy1zZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoN CjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiJz5FdmlkZW5jZQ0Kb2YgdGhlIGdy ZWF0ZXIgcm9idXNuZXNzLCBmYWlybmVzcywmbmJzcDthbmQgZWZmZWN0aXZlbmVzcyBvZiByYXRl LWJhc2VkDQpuZXR3b3JrIG1hbmFnZW1lbnQgY29udHJvbHMgaXMgZm91bmQgaW4gdGhlIGNpcmN1 aXQgc3dpdGNoZWQgUFNUTiB3aGVyZQ0KJnF1b3Q7Q2FsbCBHYXBwaW5nJnF1b3Q7IChyYXRlIGJh c2VkKSBoYXMgbWFkZSB0aGUgcGVyY2VudGFnZS1kcm9wcGVkIG5ldHdvcmsNCm1hbmFnZW1lbnQg Y29udHJvbHMgYWxsIGJ1dCBvYnNvbGV0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2 Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1z ZXJpZiInPlRoZXJlDQphcmUsIG9mIGNvdXJzZSwgbWFueSBkaWZmZXJlbmNlcyBiZXR3ZWVuIHRo ZSBQU1ROIGFuZCBhIFNJUCBuZXR3b3JrLiZuYnNwOyBCdXQNCnRoaXMgcGFydGljdWxhciBjYXNl IHNlZW1zIHRvIGJlIGEgcGxhY2Ugd2hlcmUgd2UgY2FuLCBhbmQgc2hvdWxkLCBsZWFybiBmcm9t IHRoZQ0KbGVzc29ucyBsZWFybmVkIGluIHRoZSBQU1ROLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEi LCJzYW5zLXNlcmlmIic+SmFuZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7 Y29sb3I6Izk5MDA5OSc+PGENCmhyZWY9Im1haWx0bzotLS0tLXNpcC1vdmVybG9hZC1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Ymxhbms+LS0tLS1zaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9y ZzwvYT4NCndyb3RlOiAtLS0tLTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiJz5UbzoNCiZxdW90OzxhIGhyZWY9Im1haWx0 bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmciIHRhcmdldD1ibGFuaz5zaXAtb3ZlcmxvYWRAaWV0Zi5v cmc8L2E+JnF1b3Q7DQombHQ7PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZEBpZXRmLm9yZyIg dGFyZ2V0PWJsYW5rPnNpcC1vdmVybG9hZEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KRnJvbTogSGFk cmllbCBLYXBsYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpIS2FwbGFuQGFjbWVwYWNrZXQuY29tIiB0 YXJnZXQ9Ymxhbms+SEthcGxhbkBhY21lcGFja2V0LmNvbTwvYT4mZ3Q7PGJyPg0KU2VudCBieTog PGEgaHJlZj0ibWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Ymxh bms+c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PGJyPg0KRGF0ZTogMDMvMjkvMjAx MSAxMjowOVBNPGJyPg0KU3ViamVjdDogW3NpcC1vdmVybG9hZF0gZHJhZnQtaWV0Zi1zb2Mtb3Zl cmxvYWQtY29udHJvbC0wMiBhbmQgYWxnb3JpdGhtDQphZ2lsaXR5PGJyPg0KPGJyPg0KPC9zcGFu PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn Pkhvd2R5LDxicj4NCmluIHRvZGF5J3MgV0cgc2Vzc2lvbiB0aGUgbmV3IG9jLWFsZ28gbWVjaGFu aXNtIHdhcyBkZXNjcmliZWQsIGFuZCBpdCB3YXMNCnN0YXRlZCB0aGUgV0cgaGFkIGFncmVlZCB0 byBzdXBwb3J0IG11bHRpcGxlIGFsZ29yaXRobXMsIHdpdGggYSBwb2ludGVyIHRvIHRoaXMNCnRo cmVhZDo8YnI+DQo8YQ0KaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L3NpcC1vdmVybG9hZC9jdXJyZW50L21zZzAwNDM2Lmh0bWwiDQp0YXJnZXQ9Ymxhbms+aHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcC1vdmVybG9hZC9jdXJyZW50L21zZzAw NDM2Lmh0bWw8L2E+PGJyPg0KPGJyPg0KSSBoYXZlIHJlYWQgdGhhdCB0aHJlYWQsIGFuZCB0aGVy ZSB3ZXJlIGFjdHVhbGx5IGZldyBkaXNjdXNzaW9ucyBhYm91dCB0aGUgbmVlZA0KZm9yIG11bHRp cGxlIGFsZ29yaXRobXMgKG1vc3Qgb2YgaXQgd2FzIGFib3V0IDEwMCByZXNwb25zZSBoYW5kbGlu ZyBvciBob3cNCm9mdGVuIGFsZ29yaXRobXMgd291bGQgY2hhbmdlLCBub3QgdGhlIG5lZWQgZm9y IG11bHRpcGxlIGFsZ29yaXRobXMpLjxicj4NCjxicj4NCjIgcGVvcGxlIHNlZW1lZCB0byB3YW50 IHRvIHN1cHBvcnQgbXVsdGlwbGUgYWxnb3JpdGhtcywgYnV0IGRpZCBub3QgZGVmaW5lIHdoYXQN CnRoZSAmcXVvdDtvdGhlciZxdW90OyBvbmUgd291bGQgYmUuPGJyPg0KPGJyPg0KU28gSSdtIGdv aW5nIHRvIHRyeSB0byBhcmd1ZSBmb3IgTk9UIGRvaW5nIHRoaXMgKGF0IGxlYXN0IG5vdCByaWdo dCBub3cpLg0KJm5ic3A7SGVyZSdzIHdoeTo8YnI+DQo8YnI+DQoxKSBFdmVyeSB0aW1lIHdlIGFk ZCBzb21ldGhpbmcgb3B0aW9uYWwsIGludGVyb3AgaXNzdWVzIGhhcHBlbi4gJm5ic3A7VGhlDQpw cm90b2NvbCBnZXRzIG1vcmUgY29tcGxpY2F0ZWQsIHRoZXJlJ3MgbW9yZSB0byB0ZXN0LCBtb3Jl IHRvIGZhaWwsIGV0Yy4NCiZuYnNwO0lTVE0gdGhhdCBhIG92ZXJsb2FkIGNvbnRyb2wgbWVjaGFu aXNtIHNob3VsZCBiZSBhcyBzaW1wbGUgYXMgcG9zc2libGUsDQp3aXRoIHRoZSBncmVhdGVzdCBw cm9iYWJpbGl0eSBvZiBzdWNjZXNzIGFuZCBpbnRlcm9wLiAmbmJzcDtGb3IgbWUsIHRoZSBiYXIN CndvdWxkIGhhdmUgdG8gcHJldHR5IGRhcm4gaGlnaCB0byBhZGQgb3B0aW9uYWxpdHkgLSB0aGVy ZSB3b3VsZCBoYXZlIHRvIGJlIGENCnJlYWxseSBnb29kIHJlYXNvbi48YnI+DQo8YnI+DQoyKSBD dXJyZW50bHksIHRoZXJlIGlzIG9ubHkgb25lIGFsZ29yaXRobTogbG9zcy4gJm5ic3A7T3RoZXIg YWxnb3JpdGhtcyB3ZXJlDQp0ZXN0ZWQgKHJhdGUgYW5kIHdpbmRvdyksIGJ1dCBzaW5jZSB0aGUg cmVzdWx0cyB3ZXJlIGVmZmVjdGl2ZWx5IHRoZSBzYW1lLCBpdA0Kd291bGQgc2VlbSByYXRoZXIg Zm9vbGlzaCB0byBhZGQgc3VwcG9ydCBmb3IgdGhvc2Ugb3RoZXIgdHdvLiAmbmJzcDtTbyB0aGlz DQp3b3VsZCBoYXZlIHRvIGJlIGEgNHRoLCBhcyB5ZXQgdW5rbm93biwgYWxnb3JpdGhtLiAmbmJz cDtUaGF0J3MgZmluZSwgYnV0IHdlDQpkb24ndCBuZWVkIHRvIGNyZWF0ZSBhIHBhcmFtIG9yIGxv Z2ljIHRvIGhhbmRsZSB1bmtub3duIGZ1dHVyZSBhbGdvcml0aG1zDQoqbm93Ki4gVGhpbmsgYWJv dXQgaXQgLSBub3RoaW5nIHByZXZlbnRzIGEgZnV0dXJlIGFsZ29yaXRobSBmcm9tIGFkZGluZyB0 aGlzDQpvYy1hbGdvIHBhcmFtIGluIGEgYmFja3dhcmRzLWNvbXBhdGlibGUgbWFubmVyLiAmbmJz cDtFcmdvLCB3ZSBkb24ndCBuZWVkIHRvIGRvDQppdCBub3cuICZuYnNwO0luIGZhY3QsIHNpbmNl IHdlIGRvbid0IGtub3cgdGhlIGZ1dHVyZSBhbGdvcml0aG0ocyksIHdlIGhhdmUgbm8NCmlkZWEg aWYgdGhleSBjb3VsZCBldmVuIHVzZSB0aGUgb3RoZXIgcGFyYW1zIHdlIGhhdmUuPGJyPg0KPGJy Pg0KMykgRG9pbmcgdGhpcyBpcyBub3QgYXMgdHJpdmlhbCBhcyB0aGUgZHJhZnQgY3VycmVudGx5 IGhhcyBpdC4gJm5ic3A7WW91IGNhbm5vdA0KanVzdCAmcXVvdDtuZWdvdGlhdGUmcXVvdDsgaXQg YnkgaGF2aW5nICpvbmx5KiB0aGUgY2xpZW50LXNpZGUgc2VuZCB0aGUgcGFyYW0NCmFnYWluIGlu IHRoZSBuZXh0IHJlcXVlc3Qgd2hlbiBpdCB3YW50cyB0byByZS1uZWdvdGlhdGUgaXQsIGJlY2F1 c2UgdGhlIGNsaWVudA0KaGFzIG5vIGlkZWEgd2hlbiBpdHMgbmV4dC1ob3Agc2VydmVyIGhhcyBy ZWJvb3RlZCwgb3IgdGhlIG5leHQtaG9wIHNlcnZlcidzIGhhZA0KKml0cyogY29uZmlnIGNoYW5n ZWQuICZuYnNwO0lmIHRoYXQgaGFwcGVucywgdGhlIHNlcnZlciB3b3VsZCBnZXQgYSByZXF1ZXN0 IGZvcm0NCnRoZSBjbGllbnQgd2l0aG91dCB0aGUgcGFyYW0sIGFuZCB0aHVzIHRoaW5rIHRoZSBj bGllbnQgaXMgdXNpbmcgbG9zcywgZXZlbiBpZg0KdGhleSBwcmV2aW91c2x5IG5lZ290aWF0ZWQg c29tZSBuZXcgYWxnby4gJm5ic3A7PGJyPg0KPGJyPg0KNCkgV2hlbiB5b3UncmUgdGhlIHNlcnZl ci1zaWRlLCB5b3UnbGwgbm93IGhhdmUgdG8ga2VlcCBhIG5lZ290aWF0ZWQgYWxnb3JpdGhtDQpz ZXR0aW5nIHByZSBwcmV2aW91cyBob3AgY2xpZW50LiAmbmJzcDtGb3Igc29tZSBzZXJ2ZXIgc3lz dGVtcyB0aGF0J3MgZWFzeSwgYnV0DQpmb3Igc29tZSBzZXJ2ZXJzIHRoYXQncyB1bnRlbmFibGUg LSB0aGV5IGRvbid0IGtlZXAgc3RhdGUgcGVyIHByZXZpb3VzIGhvcA0KY2xpZW50LiAmbmJzcDtB bmQgSSBiZWxpZXZlIG91ciBjaGFydGVyIHJlcXVpcmVzIHVzIHRvIHN1cHBvcnQgYSBtb2RlbCBv Zg0KdW5rbm93biBwcmV2aW91cy1ob3AgY2xpZW50cy48YnI+DQo8YnI+DQotaGFkcmllbDxicj4N Cjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0Kc2lwLW92ZXJsb2FkIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpzaXAtb3ZlcmxvYWRAaWV0Zi5vcmciIHRhcmdldD1ibGFuaz5zaXAtb3ZlcmxvYWRAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zaXAtb3ZlcmxvYWQiIHRhcmdldD1ibGFuaz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZDwvYT48L3NwYW4+PHNwYW4NCnN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiInPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4N Cg== ------_=_NextPart_001_01CBEF69.4FCA6911-- From vkg@bell-labs.com Thu Mar 31 01:50:18 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1579E3A6B2B for ; Thu, 31 Mar 2011 01:50:18 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HP9NN9kXP+yp for ; Thu, 31 Mar 2011 01:50:16 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 6B9D43A6B00 for ; Thu, 31 Mar 2011 01:50:16 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p2V8ptNS002106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 Mar 2011 03:51:55 -0500 (CDT) Received: from shoonya.ih.lucent.com (vkg.lra.lucent.com [135.244.0.140]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p2V8pstk014475 for ; Thu, 31 Mar 2011 03:51:55 -0500 (CDT) Message-ID: <4D94411B.9020307@bell-labs.com> Date: Thu, 31 Mar 2011 03:53:47 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: sip-overload@ietf.org References: <9AD888D2-CCED-4C4C-8F21-C3FA209538C3@acmepacket.com> In-Reply-To: <9AD888D2-CCED-4C4C-8F21-C3FA209538C3@acmepacket.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 Subject: Re: [sip-overload] draft-ietf-soc-overload-control-02 and algorithm agility X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 08:50:18 -0000 Hadriel: Please see inline. On 03/29/2011 11:09 AM, Hadriel Kaplan wrote: > Howdy, in today's WG session the new oc-algo mechanism was described, > and it was stated the WG had agreed to support multiple algorithms, > with a pointer to this thread: > http://www.ietf.org/mail-archive/web/sip-overload/current/msg00436.html [...] > So I'm going to try to argue for NOT doing this (at least not right > now). Here's why: > > 1) Every time we add something optional, interop issues happen. [...] Hadriel: Indeed, I am sympathetic to that as well. > 2) Currently, there is only one algorithm: loss. Other algorithms > were tested (rate and window), but since the results were effectively > the same, it would seem rather foolish to add support for those other > two. So this would have to be a 4th, as yet unknown, algorithm. > That's fine, but we don't need to create a param or logic to handle > unknown future algorithms *now*. Think about it - nothing prevents a > future algorithm from adding this oc-algo param in a > backwards-compatible manner. Ergo, we don't need to do it now. In > fact, since we don't know the future algorithm(s), we have no idea if > they could even use the other params we have. Just so that we are all on the same page, Hadriel is arguing that we do not have the "oc-algo" parameter at all. We go with the loss- based algorithm right now, and if that does not work then at some future time we have an updated RFC that adds the new "oc-algo" Via parameter. The backward compatibility will be acheived by older implementations defaulting to using loss-based because they will not have the context to understand the new "oc-algo" parameter. I think this is reasonable, especially since it cuts out the complexity listed next: > 3) Doing this is not as trivial as the draft currently has it. You > cannot just "negotiate" it by having *only* the client-side send the > param again in the next request when it wants to re-negotiate it, > because the client has no idea when its next-hop server has rebooted, > or the next-hop server's had *its* config changed. If that happens, > the server would get a request form the client without the param, and > thus think the client is using loss, even if they previously > negotiated some new algo. Yes, I am sympathetic to this as well. Although the current text says that the algorithms must not be re-negotiated frequently, it does not define the interval. RjS pointed out that this will create interoperability problems. And since the renegotiation is driven by the client, there are the other problems you mention above. > 4) When you're the server-side, you'll now have to keep a negotiated > algorithm setting pre previous hop client. For some server systems > that's easy, but for some servers that's untenable - they don't keep > state per previous hop client. And I believe our charter requires us > to support a model of unknown previous-hop clients. Right; btw, keeping less state in the server is an argument to pick loss-based as the default algorithm instead of rate-based. The latter requires the server to assign --- and keep track --- of a share of its overall capacity with each upstream client. In summary, I think it is worth debating Hadriel's point 2 above, i.e., should we put algorithm negotiation right now or do it later in a backwards compatible manner. Thoughts? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From vkg@bell-labs.com Thu Mar 31 01:53:34 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0412028C0FE for ; Thu, 31 Mar 2011 01:53:34 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gix-baeW8GQ for ; Thu, 31 Mar 2011 01:53:32 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 90C8A28C11B for ; Thu, 31 Mar 2011 01:53:32 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p2V8t9K7003548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Mar 2011 03:55:09 -0500 (CDT) Received: from shoonya.ih.lucent.com (vkg.lra.lucent.com [135.244.0.140]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p2V8t7qv016107; Thu, 31 Mar 2011 03:55:08 -0500 (CDT) Message-ID: <4D9441DC.3000800@bell-labs.com> Date: Thu, 31 Mar 2011 03:57:00 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: Hadriel Kaplan References: <9AD888D2-CCED-4C4C-8F21-C3FA209538C3@acmepacket.com> <77199F7F-CC15-4113-AAF6-11654FC5C76B@acmepacket.com> In-Reply-To: <77199F7F-CC15-4113-AAF6-11654FC5C76B@acmepacket.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 Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] draft-ietf-soc-overload-control-02 and algorithm agility X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 08:53:34 -0000 On 03/29/2011 05:50 PM, Hadriel Kaplan wrote: > But that to me argues we shouldn't pick the loss-based one to begin with. > Either they're all effectively the same, or they're not. As far as I > know, the results of the design-team were they were the same, so the > loss based one was picked just because it's the simplest to implement. > If a rate-based is instead more effective, even if it's just for "corner > cases", then we should pick that one instead. The rate-based one requires more state in the server. Keeping less state in the server is an argument to pick loss-based as the default algorithm instead of rate-based. The latter requires the server to assign --- and keep track --- of a share of its overall capacity with each upstream client. There is a good discussion of this in the design document [1], Sections 9.1 and 9.2. [1] http://tools.ietf.org/html/draft-ietf-soc-overload-design-05 Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From volker.hilt@alcatel-lucent.com Thu Mar 31 02:07:59 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED4FB28C1F0 for ; Thu, 31 Mar 2011 02:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3MYw2TpKIyP for ; Thu, 31 Mar 2011 02:07:58 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id A10BE28C1E9 for ; Thu, 31 Mar 2011 02:07:58 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p2V99akQ000268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 31 Mar 2011 04:09:36 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2V99aVU007868 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 31 Mar 2011 04:09:36 -0500 Received: from [135.104.20.65] (135.3.63.242) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 31 Mar 2011 04:09:34 -0500 Message-ID: <4D9444C3.6080103@alcatel-lucent.com> Date: Thu, 31 Mar 2011 11:09:23 +0200 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: References: <9AD888D2-CCED-4C4C-8F21-C3FA209538C3@acmepacket.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; 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.10 Subject: Re: [sip-overload] draft-ietf-soc-overload-control-02 and algorithm agility X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 09:08:00 -0000 The SIP overload control design team had spent quite some time on comparing the different types of algorithms. A summary of the results of the simulations that were run was presented in SIPPING at IETF 74: http://www.ietf.org/proceedings/74/slides/sipping-11/sipping-11.htm These results indicate that there is little difference between the different types of algorithms. The design team had evaluated the algorithms under a range of conditions. Details are in the slides above. More inline. > While both loss based and rate based algorithms work well in a simulated > environment, driven by random processes, there are a number of highly > probable real world scenarios (e.g. highly localized source of overload, > or rapidly varying overload) in which a loss based algorithm is either > ineffective or unfair. Do you have pointers to results that show that the loss based algorithms is ineffective or unfair in a SIP network? It would be helpful to back these statements up with results otherwise we end up guessing what may or may not happen in a network. The design team has evaluated scenarios with rapidly changing load conditions and fairness among sources. The results are in the slides above. Both loss and rate-based mechanisms worked well in all the scenarios we have evaluated. > Evidence of the greater robusness, fairness, and effectiveness of > rate-based network management controls is found in the circuit switched > PSTN where "Call Gapping" (rate based) has made the percentage-dropped > network management controls all but obsolete. > There are, of course, many differences between the PSTN and a SIP > network. But this particular case seems to be a place where we can, and > should, learn from the lessons learned in the PSTN. Again, I'd like to see these claims backed up with results for a SIP server. The members of the design team did not find these evidences. Thanks, Volker > -----sip-overload-bounces@ietf.org wrote: ----- > > To: "sip-overload@ietf.org" > From: Hadriel Kaplan > Sent by: sip-overload-bounces@ietf.org > Date: 03/29/2011 12:09PM > Subject: [sip-overload] draft-ietf-soc-overload-control-02 and > algorithm agility > > Howdy, > in today's WG session the new oc-algo mechanism was described, and > it was stated the WG had agreed to support multiple algorithms, with > a pointer to this thread: > http://www.ietf.org/mail-archive/web/sip-overload/current/msg00436.html > > I have read that thread, and there were actually few discussions > about the need for multiple algorithms (most of it was about 100 > response handling or how often algorithms would change, not the need > for multiple algorithms). > > 2 people seemed to want to support multiple algorithms, but did not > define what the "other" one would be. > > So I'm going to try to argue for NOT doing this (at least not right > now). Here's why: > > 1) Every time we add something optional, interop issues happen. The > protocol gets more complicated, there's more to test, more to fail, > etc. ISTM that a overload control mechanism should be as simple as > possible, with the greatest probability of success and interop. For > me, the bar would have to pretty darn high to add optionality - > there would have to be a really good reason. > > 2) Currently, there is only one algorithm: loss. Other algorithms > were tested (rate and window), but since the results were > effectively the same, it would seem rather foolish to add support > for those other two. So this would have to be a 4th, as yet unknown, > algorithm. That's fine, but we don't need to create a param or logic > to handle unknown future algorithms *now*. Think about it - nothing > prevents a future algorithm from adding this oc-algo param in a > backwards-compatible manner. Ergo, we don't need to do it now. In > fact, since we don't know the future algorithm(s), we have no idea > if they could even use the other params we have. > > 3) Doing this is not as trivial as the draft currently has it. You > cannot just "negotiate" it by having *only* the client-side send the > param again in the next request when it wants to re-negotiate it, > because the client has no idea when its next-hop server has > rebooted, or the next-hop server's had *its* config changed. If that > happens, the server would get a request form the client without the > param, and thus think the client is using loss, even if they > previously negotiated some new algo. > > 4) When you're the server-side, you'll now have to keep a negotiated > algorithm setting pre previous hop client. For some server systems > that's easy, but for some servers that's untenable - they don't keep > state per previous hop client. And I believe our charter requires us > to support a model of unknown previous-hop clients. > > -hadriel > > > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > > From volker.hilt@alcatel-lucent.com Thu Mar 31 02:27:15 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85CBC28C23F for ; Thu, 31 Mar 2011 02:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBzzBiFvOmyY for ; Thu, 31 Mar 2011 02:27:14 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 628DF28C26E for ; Thu, 31 Mar 2011 02:23:59 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p2V9Pc4g018631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 31 Mar 2011 04:25:39 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2V9PcP3013562 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 31 Mar 2011 04:25:38 -0500 Received: from [135.104.20.65] (135.3.63.242) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 31 Mar 2011 04:25:33 -0500 Message-ID: <4D944880.9090603@alcatel-lucent.com> Date: Thu, 31 Mar 2011 11:25:20 +0200 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: References: <9AD888D2-CCED-4C4C-8F21-C3FA209538C3@acmepacket.com> In-Reply-To: <9AD888D2-CCED-4C4C-8F21-C3FA209538C3@acmepacket.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.10 Subject: Re: [sip-overload] draft-ietf-soc-overload-control-02 and algorithm agility X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 09:27:15 -0000 Hadriel, > 2) Currently, there is only one algorithm: loss. Other algorithms > were tested (rate and window), but since the results were effectively > the same, it would seem rather foolish to add support for those other > two. So this would have to be a 4th, as yet unknown, algorithm. > That's fine, but we don't need to create a param or logic to handle > unknown future algorithms *now*. Think about it - nothing prevents a > future algorithm from adding this oc-algo param in a > backwards-compatible manner. Ergo, we don't need to do it now. In > fact, since we don't know the future algorithm(s), we have no idea if > they could even use the other params we have. > I agree. An extension mechanism can be added in the future as you point out when it becomes necessary for some reason. I.e., the first extension would have to define the extension mechanism. This can be done in a backwards compatible way the does not break things. > 3) Doing this is not as trivial as the draft currently has it. You > cannot just "negotiate" it by having *only* the client-side send the > param again in the next request when it wants to re-negotiate it, > because the client has no idea when its next-hop server has rebooted, > or the next-hop server's had *its* config changed. If that happens, > the server would get a request form the client without the param, and > thus think the client is using loss, even if they previously > negotiated some new algo. The client needs to send the algo parameter in every request, not only when it renegotiates. That will keep things fairly simple. The client sends the algorithms it supports. The server responds with an oc value for one of the algorithms and an indication which algorithm it is. The server decides which algorithm that was offered by the client it wants to use. The response needs to contain a parameter saying with algorithm it is. No parameter would mean the default. With this, reboots of either side will not be a problem. Since we have a mandatory to implement default algorithm, interoperability should also not be a problem. Having said that, I believe this extension mechanism can be added when the first extension is defined. Thanks, Volker > 4) When you're the server-side, you'll now have to keep a negotiated > algorithm setting pre previous hop client. For some server systems > that's easy, but for some servers that's untenable - they don't keep > state per previous hop client. And I believe our charter requires us > to support a model of unknown previous-hop clients. > > -hadriel > > > > _______________________________________________ sip-overload mailing > list sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From volker.hilt@alcatel-lucent.com Thu Mar 31 02:30:36 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DEFE28C20C for ; Thu, 31 Mar 2011 02:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3rWqrGuG233 for ; Thu, 31 Mar 2011 02:30:35 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 9242F28C21D for ; Thu, 31 Mar 2011 02:29:21 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p2V9V0Bc021063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 31 Mar 2011 04:31:00 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2V9V0ZW013646 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 31 Mar 2011 04:31:00 -0500 Received: from [135.104.20.65] (135.3.63.242) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 31 Mar 2011 04:30:57 -0500 Message-ID: <4D9449CC.80909@alcatel-lucent.com> Date: Thu, 31 Mar 2011 11:30:52 +0200 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: References: <9AD888D2-CCED-4C4C-8F21-C3FA209538C3@acmepacket.com> <4D94411B.9020307@bell-labs.com> In-Reply-To: <4D94411B.9020307@bell-labs.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.11 Subject: Re: [sip-overload] draft-ietf-soc-overload-control-02 and algorithm agility X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 09:30:36 -0000 Yes, I'm for leaving the extension mechanism for a future draft. It seems that creating such a mechanism at a later point is feasible. Volker (as individual) On 3/31/2011 10:53 AM, Vijay K. Gurbani wrote: > Hadriel: Please see inline. > > On 03/29/2011 11:09 AM, Hadriel Kaplan wrote: > > Howdy, in today's WG session the new oc-algo mechanism was described, > > and it was stated the WG had agreed to support multiple algorithms, > > with a pointer to this thread: > > http://www.ietf.org/mail-archive/web/sip-overload/current/msg00436.html > [...] > > So I'm going to try to argue for NOT doing this (at least not right > > now). Here's why: > > > > 1) Every time we add something optional, interop issues happen. [...] > > Hadriel: Indeed, I am sympathetic to that as well. > > > 2) Currently, there is only one algorithm: loss. Other algorithms > > were tested (rate and window), but since the results were effectively > > the same, it would seem rather foolish to add support for those other > > two. So this would have to be a 4th, as yet unknown, algorithm. > > That's fine, but we don't need to create a param or logic to handle > > unknown future algorithms *now*. Think about it - nothing prevents a > > future algorithm from adding this oc-algo param in a > > backwards-compatible manner. Ergo, we don't need to do it now. In > > fact, since we don't know the future algorithm(s), we have no idea if > > they could even use the other params we have. > > Just so that we are all on the same page, Hadriel is arguing that > we do not have the "oc-algo" parameter at all. We go with the loss- > based algorithm right now, and if that does not work then at some > future time we have an updated RFC that adds the new "oc-algo" Via > parameter. The backward compatibility will be acheived by older > implementations defaulting to using loss-based because they will > not have the context to understand the new "oc-algo" parameter. > > I think this is reasonable, especially since it cuts out the > complexity listed next: > > > 3) Doing this is not as trivial as the draft currently has it. You > > cannot just "negotiate" it by having *only* the client-side send the > > param again in the next request when it wants to re-negotiate it, > > because the client has no idea when its next-hop server has rebooted, > > or the next-hop server's had *its* config changed. If that happens, > > the server would get a request form the client without the param, and > > thus think the client is using loss, even if they previously > > negotiated some new algo. > > Yes, I am sympathetic to this as well. Although the current text > says that the algorithms must not be re-negotiated frequently, it > does not define the interval. RjS pointed out that this will > create interoperability problems. And since the renegotiation is > driven by the client, there are the other problems you mention > above. > > > 4) When you're the server-side, you'll now have to keep a negotiated > > algorithm setting pre previous hop client. For some server systems > > that's easy, but for some servers that's untenable - they don't keep > > state per previous hop client. And I believe our charter requires us > > to support a model of unknown previous-hop clients. > > Right; btw, keeping less state in the server is an argument to pick > loss-based as the default algorithm instead of rate-based. The > latter requires the server to assign --- and keep track --- of a > share of its overall capacity with each upstream client. > > In summary, I think it is worth debating Hadriel's point 2 > above, i.e., should we put algorithm negotiation right > now or do it later in a backwards compatible manner. > > Thoughts? > > Thanks, > > - vijay From volker.hilt@alcatel-lucent.com Thu Mar 31 03:17:11 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F5DD28C0EA for ; Thu, 31 Mar 2011 03:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RglstcSVtIG for ; Thu, 31 Mar 2011 03:17:10 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id DB0BF28C0D8 for ; Thu, 31 Mar 2011 03:17:09 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p2VAInsD025346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 31 Mar 2011 05:18:49 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p2VAIm5U026244 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 31 Mar 2011 05:18:48 -0500 Received: from [135.104.20.65] (135.3.63.242) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 31 Mar 2011 05:18:48 -0500 Message-ID: <4D945510.8000409@alcatel-lucent.com> Date: Thu, 31 Mar 2011 12:18:56 +0200 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: References: <4D3876BF.9050009@bell-labs.com> <9ECCF01B52E7AB408A7EB85352642141027CFAFE@ftrdmel0.rd.francetelecom.fr> <4D503A57.6070206@bell-labs.com> <9ECCF01B52E7AB408A7EB8535264214102810BAC@ftrdmel0.rd.francetelecom.fr> <4D51BF4B.5070500@alcatel-lucent.com>, <4D52AE9B.4070901@bell-labs.com> 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.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [sip-overload] Comments on draft-ietf-soc-overload-control-02 - was Re: draft-ietf-soc-overload-control-01 submitted X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 10:17:11 -0000 > > Meeting Req 2 > > But, the upstream node is permitted to send the rejected messages o > other nodes, possibly overloading them. > The draft discourages this behavior. > Meeting REQ 4 > > But if an UPSTREAM node does not support this mechanism, it may generate > more downstream traffic than has been throttles by the conforming nodes, > and the downstreamnode9s0 will continue to be overloaded. > I believe this is within what is required by REQ 4: In other words, the mechanism should not work only in environments where all elements support it. It is reasonable to assume that it works better in such environments, of course. The draft discusses how to mitigate the impact of traffic from elements that don't support it and the reduction of traffic from elements that do support the draft will help to reduce overload. > Meeting REQ 16 > > It is not clear to me why being in the Via header “minimizes overhead”. > I believe the argument is that there is very little additional protocol complexity added by this mechanism. > Meeting REQ 18 > > I would say “partial”, as it leaves it to local policy.The mechanism > ITSELF does not address which messages to drop. > REQ 18 is about identifying a server (not the messages to drop). REQ 19 (which you were probably referring to): the draft does give guidance on which messages to drop. It does leave the possibility for local policy but that seems to be within this requirement. > Meeting REQ 20. > > I think this should be NO.An upstream node that does not implement this > mechanism WILL receive a significant measure of extra benefit. > I believe this should be a partial. The draft discusses how to address this problem using local overload control. As long as the overload from the non-compliant servers does not exceed the limit of what can be done using local overload control, it does not receive extra benefit. If the load from these servers passes that point, the server may run into overload (in which case all servers are affected). > Meeting REQ 23 > > Since it still “depends on the type of load balancer”, I think this > should be “partial”. > The draft discusses both sip-aware and non-sip-aware load balancers. Which case is not addressed? Thanks, Volker > > -----sip-overload-bounces@ietf.org wrote: ----- > > To: sip-overload@ietf.org > From: "Vijay K. Gurbani" > Sent by: sip-overload-bounces@ietf.org > Date: 02/09/2011 10:11AM > Subject: Re: [sip-overload] draft-ietf-soc-overload-control-01 submitted > > On 02/08/2011 04:10 PM, Volker Hilt wrote: > > Vijay, Bruno, following the discussion above - I believe that > REQ-23 can > > in fact be met for load balancers that are not SIP aware. Of course, > > there is always a way to build a system that does not work. But > the key > > point is that this requirement can be met with the correct design. > > > > My suggestion would be to document these approaches in the draft > as this > > will be very relevant for implementers. > > > > I think with this documentation, a "Yes" to REQ-23 is appropriate. > > OK, this is more work for me then simply changing a "Yes" to "Partial". > But, I will go ahead and do so. If we need more discussion around > this, we should hold it now before I update the draft and summarize > the current discussion ... > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > >