From tasveren@sonusnet.com Tue Dec 1 11:18:24 2009 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 5DA573A687D for ; Tue, 1 Dec 2009 11:18:24 -0800 (PST) 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 2EhJVl8XQtkP for ; Tue, 1 Dec 2009 11:18:23 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 391DA3A6831 for ; Tue, 1 Dec 2009 11:18:23 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id nB1JIFhM010451 for ; Tue, 1 Dec 2009 14:18:15 -0500 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: Tue, 1 Dec 2009 14:17:10 -0500 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7029CA3C0@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-hilt-sipping-overload-07 Thread-Index: AcpyuuGzC+UZVt/ST9atwkiTkcUtHQ== From: "Asveren, Tolga" To: Subject: [sip-overload] Review of draft-hilt-sipping-overload-07 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, 01 Dec 2009 19:18:24 -0000 Overall the draft is in pretty good shape and I hope it can move forward quickly. It is needed :-) A few comments/questions: 1) Why is there a need to remove oc_accept from the topmost Via header. Wouldn't that Via header be removed by the next-hop upstream element (which has inserted this Via header together with oc_accept)?=20 2) What are the exact semantics for oc_validity? For example if an element receives a response with oc_validity=3D1000, is it supposed to ignore the oc values in responses received during the next 1000ms? 3) It could be useful to mention that with retransmissions of the response an oc value consistent with the overload condition at the time of retransmission must be used. 4) Forwarding oc parameter: Even mentioning this sounds a bit risky to me. If some text is seen as necessary, I would prefer something like: "An element may consider the oc parameter values it received from downstream elements, when deciding for the oc parameter value it is going to send to its upstream neighbors. This, for example, could be meaningful in cases where an element knows that all traffic to the downstream elements in questions flow through itself." 5) About the OPEN ISSUE: I think it is important to agree on a single way of communicating overload information for the sake of better interoperability. I think loss ratio is a good choice (considering also design issues). 6) oc parameter value is used in a way where it is applied to all requests. Dropping a percentage of dialogue initiating requests could be a more useful semantic. This requires that oc parameter is generated/consumed with this new meaning. Has this been already considered? 7) It may be too aggressive to stop traffic with a single timeout error. It may be best not to specify how many timeout errors should cause stopping traffic. 8) According to RFC3261 503 without Retry-After needs to be handled as 500 Server Error. I just wanted to pint this out as for upstream elements, which don't support the overload control mechanism defined in this draft, this will be the effective response code. I think the rationale behind not using Retry-After is to prevent oscillation but I don't know what the behavior is going to be with 500. 9) It could be nice to say a few words about servers being careful about preventing oscillation when calculating oc values. I am not really looking for an exact algorithm but just pointing this out explicitly. 10) I also want to add that I share the concerns listed in the draft about using an event package. Thanks, Tolga From charles.newyork@gmail.com Wed Dec 2 13:59:13 2009 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 1B3D43A6836 for ; Wed, 2 Dec 2009 13:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 Vld+IZHtO+24 for ; Wed, 2 Dec 2009 13:59:12 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 519883A67D9 for ; Wed, 2 Dec 2009 13:59:09 -0800 (PST) Received: by pwi19 with SMTP id 19so530689pwi.29 for ; Wed, 02 Dec 2009 13:58:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=pHuNJbEC7h/UC0orGUHOmpTvlPcNYzxnoiCvjE1Qey0=; b=tcqFH9LgyMad/hFWRKrU80ayIXm9X0WFoOU8rPP5oF6rRmsOwdN9hESANqhyb0pCUb iUPmGCeHrVwVUemAlY4oRjjF+rwxDgy9zZ3rEoGtPvKC/KzZJplgXR3zLK5IBv6Zgkoi 1DtELI8QkYpCBzLy4xBVTih0MmsUX4DuIydmY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=rW/N4padNPBC9ytLOnUg/z64rFJIfwB3r9Zy+8IUv/0f857Vb/z+nxS0hY79JRhrR8 +sB/01sTe7OpQ2sFir1sTiC+fM7Ve0Evpp7JsTED7Sh3Eo/6rjqAHyhiZ3anpaOVYBUo oFvS9H7+bkP48Brl7I9K/Ohg4WBshpAGvB7PI= MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.142.122.6 with SMTP id u6mr77772wfc.95.1259791138845; Wed, 02 Dec 2009 13:58:58 -0800 (PST) In-Reply-To: References: Date: Wed, 2 Dec 2009 16:58:58 -0500 X-Google-Sender-Auth: 907150977b45e483 Message-ID: From: Charles Shen To: "Moran, Timothy L." Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Volker Hilt , sip-overload@ietf.org, Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] FW: A few comments/questions on the overload drafts 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, 02 Dec 2009 21:59:13 -0000 Hi Moran, thanks and comments inline. > Draft-shen-sipping-load-control-event-package-03.txt > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 8.2: =E2=80=9CWhen the user is iden= tified by the source and a favorable > action is specified, the result may be comparable to identifying a priori= ty > user based on authorized Resource Priority Headers {RFC 4412} in the > requests.=E2=80=9D=C2=A0=C2=A0=C2=A0 I=E2=80=99m not sure this is compara= ble since the invocation of > priority calls is regulated to be for emergency purposes only.=C2=A0 Thus= , a fire > chief ordering pizza does not constitute the need for priority treatment = =E2=80=93 > even though the source is an authorized priority service user. > "Comparable" is in the sense that certain calls will be treated favorably over others. If a fire chief orders pizza using a GETS phone, I suspect it will be difficult for the system to tell whether this is a real emergency either. But maybe we can find better wording here. > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4.4: =E2=80=9CTherefore, the entity= that initiates the filter needs to take > counter-measures towards any non-conforming neighbors. A simple mode is t= o > just drop excessive requests=E2=80=A6=E2=80=9D=C2=A0 Should this section = (paragraph) note the > possibility of using priority policy as in RFC 4412 before =E2=80=9Cdropp= ing=E2=80=9D > requests?=C2=A0 It is recognized that section 8.1 mentions this, but this= section > especially warrants reference to 4412 (IMHO). I think we can mention that RFC 4412 should be honored when making those dropping decisions (essentially the overload control is not the sole decision maker). > > Is it possible (in the future) to provide an example scenario (or two) of > how the shen and hilt drafts are complementary =E2=80=93 a BCP for their = combined > use so to speak? I think that would be helpful, when both drafts have achieved sufficient maturity. Thanks Charles > > BR, > > Timothy Moran > > 703-676-2334 (W) > > 571-268-0858 (C) > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > > From charles.newyork@gmail.com Thu Dec 3 06:31:24 2009 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 0002B28C161 for ; Thu, 3 Dec 2009 06:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 BLkSWWuC2VFg for ; Thu, 3 Dec 2009 06:31:23 -0800 (PST) Received: from mail-pz0-f187.google.com (mail-pz0-f187.google.com [209.85.222.187]) by core3.amsl.com (Postfix) with ESMTP id 57D7428C159 for ; Thu, 3 Dec 2009 06:31:23 -0800 (PST) Received: by pzk17 with SMTP id 17so1344900pzk.6 for ; Thu, 03 Dec 2009 06:31:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=3oP4SsG8bV5LnpjsjA00z2Fy1JMGBRjNZaYSN5QJogI=; b=V4S930KJjkOYcDmpdyr7ntcM1lsxrB75ngrs0pFqgXt7RGHAs5RVnMG0pIrLcbC368 6r7IYrJCFZsfsFfN/OVXFxdf7IpQ1c38eVp0A5RVyin1+CRxREccLev/ZC0idHhrYnGX pVxusbbS3dvTxWAC1Qb0vojL4JtXbCpgjpaQU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=uNqEFXUwMMZVTFGnv+XipH0OoQoXpk03W8oF3grOpxRJh4BttFKv3gllFUlomU4rYM AQUFfAWOthhLrIKuZ320ktBhGfCY9yn6waKHSSSVjR/cJgblcOl+DdGuj1E1oiqOAvTb //vze+IuNVgt1qDE3RqRy4CuW4EaGPMqVJVqs= MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.143.26.37 with SMTP id d37mr195821wfj.222.1259850671704; Thu, 03 Dec 2009 06:31:11 -0800 (PST) In-Reply-To: References: Date: Thu, 3 Dec 2009 09:31:11 -0500 X-Google-Sender-Auth: ba00f1e31ae18af8 Message-ID: From: Charles Shen To: sip-overload@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Arata Koike , Henning Schulzrinne Subject: [sip-overload] Fwd: draft-shen-sipping-avalanche-restart-overload-00 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, 03 Dec 2009 14:31:24 -0000 Hi all, we've submitted the following draft, comments appreciated. A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart Overload Control http://tools.ietf.org/html/draft-shen-sipping-avalanche-restart-overload-00 Abstract =C2=A0 When a large number of clients register with a SIP registrar server =C2=A0 at approximately the same time, the server may become overloaded. =C2=A0 Near-simultaneous floods of SIP SUBSCRIBE and PUBLISH requests may =C2=A0 have similar effects. =C2=A0Such request avalanches can occur, for =C2=A0 example, after a power failure and recovery in a metropolitan area. =C2=A0 This document describes how to avoid such overload situations. =C2= =A0Under =C2=A0 this mechanism, a server estimates an avalanche restart backoff =C2=A0 interval during its normal operation and conveys this interval to it= s =C2=A0 clients through a new Register-Restart header in registration =C2=A0 responses. =C2=A0Once an avalanche restart actually occurs, the clie= nts =C2=A0 perform backoff based on the previously received Register-Restart =C2=A0 header value before sending out the first registration attempt. =C2=A0 Thus, the mechanism spreads all the initial client registration =C2=A0 requests and prevents them from overloading the registrar server. Thanks Charles From geoff.hunt@bt.com Tue Dec 15 07:10:41 2009 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 04B9E3A6A3C for ; Tue, 15 Dec 2009 07:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 DsS0WY7KNMZd for ; Tue, 15 Dec 2009 07:10:37 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 616F43A6A56 for ; Tue, 15 Dec 2009 07:10:35 -0800 (PST) Received: from E03MVY2-UKDY.domain1.systemhost.net ([193.113.30.58]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Dec 2009 15:10:19 +0000 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: Tue, 15 Dec 2009 15:10:17 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-hilt-sipping-overload-07 Thread-Index: Acp9mLYQz7uIyC+NQPyB1dVPnRyDAg== From: To: , X-OriginalArrivalTime: 15 Dec 2009 15:10:19.0985 (UTC) FILETIME=[B7748C10:01CA7D98] Subject: [sip-overload] Comments on draft-hilt-sipping-overload-07 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, 15 Dec 2009 15:10:41 -0000 Hi Volker, All, Here are some comments on the draft. I've also tried to assess the proposal by estimating the compliance against the 23 requirements in RFC 5390, and this attempt at a compliance statement is at the end of this post. I will send some comments on draft-shen-sipping-load-control-event-package-03 in a separate post. 1) General. The informational design material in section 6 seems out of place in this normative draft. If design is not final, would it be better to have competing drafts describing differing candidate approaches, and seek the community view? 2) General. There is no mention of the UDP retransmission problem in overload and whether INVITE retransmission should be suppressed towards an overloaded entity. Is it assumed that a reliable transport is used? 3) Introduction paragraph 2, text "does not have sufficient resources to process all incoming SIP messages". Should this be qualified with a statement about delay, for example "within a delay which does not cause users to abandon and retry their session attempt"? 4) Section 3.1. The first paragraph of 3.1 specified addition of oc_accept only to a SIP *request* towards downstream neighbours. The second paragraph refers to removing an oc_accept before forwarding a *response*. Is an oc_accept ever sent with a response? 5) Section 3.2, third paragraph. Section 3.1 was confusing over whether oc_accept is in responses or only in requests. Does the text in Section 3.2 paragraph 3 mean that "oc" should be added to responses replying to requests which contained an "oc_accept"? Or, is the text "A SIP server SHOULD add an 'oc' parameter to responses, that contain an 'oc_accept' parameter in the topmost Via header" literally true, that is, implying that the *response* contains an oc_accept? 6) section 3.2 paragraph 4. text "The 'oc_validity' parameter defines the time in milliseconds during which the content (i.e., the overload control feedback) of the 'oc' parameter is valid ." What does the upstream server do when the period of validity expires? 500 ms seems very short if the semantics are to cease control - if the downstream server wants to remove the control, it should send a new current value. 7) section 3.5 paragraph 1. "The SIP server MUST NOT forward more messages to a SIP server than allowed by the current 'oc' parameter value from this server." Whilst this statement has a meaning in the context of a parameter controlling fractional loss, it doesn't have much normative benefit in terms of load on the downstream server, given that traffic offered to the control can vary by large factors and that traffic admitted through the fractional-loss control will vary by the same factor. The likely underlying requirement to stabilise load is more easily met by a rate-based control such as a leaky bucket. 8) Section 3.5 paragraph 2, text "An alternative algorithm... reject/redirect the first X of every 100...". The bursty arrival process resulting from this algorithm will increase mean processing delay and may lead to difficulty in estimating load at the overloaded server. It should not be proposed. 9) Section 4 text "An element can also buffer requests in the hope that the overload condition will resolve quickly and the requests still can be forwarded in time". This seems dangerous - is any limit placed on the amount of load which could be stored, and for how long, and how quickly load is released if the overload is believed to have dissipated? I favour a "SHOULD NOT" statement about such buffering. If a user wants to initiate a session, they can always retry. 10) Section 4.2 paragraph 1 text "This response indicates...". 503 was selected by the overloaded server because it knows that it is overloaded, but it cannot be said that 503 "indicates" this to an upstream server, because 503 is ambiguous. 11) Section 4.2 paragraph 2, text "The fraction of requests rejected SHOULD be equivalent to the fraction of requests the upstream server would reject/redirect if it did support this specification." This appears to be an unrealistic objective. If the upstream server does not support "oc" then the downstream server must bear the cost of rejecting some session requests as well as the cost of processing other requests to completion. It would be "fair" to devote the same amount of processing at the overloaded server to the combination of rejection and processing, as the overloaded server would devote to processing requests from an "oc-compliant" upstream server. 12) Section 6.1.1 bullet 2, text " It also enables the use of overload control mechanisms that use regular feedback such as window-based overload control ." How is this true given that the semantics of "oc" are defined specifically as a % loss fraction? 13) Section 6.1.2 bullet 2, text " However, these notifications do generate additional traffic, which adds to the overall load ." True, but the notification scheme does not require additional operations on call request and response messages for every SIP call, which are required by the scheme favoured in the draft, and the trade-off could go either way. 14) Section 6.1.2 bullet 5, text "As overload feedback is sent to all senders in separate messages, this [event] mechanism is not suitable when frequent overload control feedback is needed." Whether this "not suitable" statement is true depends on how frequently feedback is needed, and the number of senders. For example a leaky-bucket based rate control can greatly reduce the frequency at which overload control feedback is needed, by bounding the rate at which upstream elements send traffic downstream, independent of the rate of arrival of new traffic at the upstream servers. 15) Section 6.1, last sentence, " This document defines a new Via header field parameter for overload control ." This statement seems out of context. Is it present to convey the message "We have rejected the event package approach and we define instead a header field"? If so, it might be better to state this explicitly. Estimated compliance against 23 requirements of RFC 5390: R1. Design would not prevent an OLC algorithm from meeting Req #1. R2. Design allows Req #2 to be met - including 3.6 on self-limiting behaviour in the absence of responses from downstream R3. Use of proportional scheme minimises configuration but would not prevent use, e.g. with configuration to implement a custom fairness scheme. R4. Design covers behaviours in networks containing a mixture of compliant and non-compliant servers. R5. Design includes schemes for dealing with non-compliant or malicious elements, although proportional control scheme makes it slightly harder to determine whether an element is complying R6. Overload of the server is signalled with a specific message (header), however the 503 response is still used in response to individual session requests and is not augmented to reduce the current ambiguity. R7. Graded throttling, compliant R8. Retrying, or not, on another element is nodal behaviour, but the draft recommends that the upstream node should not retry at an overloaded alternative R9. Retrying on another element which is not overloaded is not prevented by the design R10. Design does not cover servers receiving requests from a very large number of upstream devices, e.g. UAs. R11. Design covers servers receiving requests from finite set of upstream elements R12. Design supports control between domains R13. The design does not limit nodal behaviours to respect priority R14. The mechanism does not provide explicit guidance on when to retry TCP connection establishment or SIP registration R15. The mechanism suggests behaviours to deal with downstream servers which are broken or isolated R16. Given the design choice to include overload information in every message, the mechanism is fairly lightweight. The alternative of providing overload control information in parallel, and only as often as required, is explicitly rejected R17. The mechanism probably assists in reducing the impact of DDoS attacks by throttling traffic close to source and maintaining some session processing capability in network regions away from the source, unless the attack is widespread and focused. It's suggested that fraudulent use of the mechanism may be avoided by use of TLS. R18. The mechanism does not state explicitly whether the overload indication applies to an IP address, host or URI, so an upstream host may not be able to determine a level at which it should retry. Instead the indication is hop-by-hop. See also comment re req 23. R19. This protocol design does not give guidance on which message types should be given priority in processing during overload. R20. In a mixed environment of elements which do and don't implement the mechanism, local rejection can prevent disproportionate benefit accruing to elements which do not implement the mechanism. However local rejection is more costly than remote rejection so overall throughput will be reduced by having elements in the network which do not support the mechanism. R21. The mechanism could be used in an overload control mechanism which, overall, is stable - though the draft does not provide guidance on algorithms which could achieve this. R22. It would be possible to implement a node which could be configured not to send load information to certain upstream sources R23. The mechanism as defined is hop-by-hop so care would be needed with a load-balancer which is itself not overloaded in front of a farm of proxies all of which are overloaded. The load balancer should send control information upstream if, and only if, all of its server farm are fully loaded. The load balancer should ensure that requests are forwarded to an individual server in the farm only if the load balancer expects that the server has sufficient resource to process the request to completion. Hope this helps. Geoff Hunt BT Design Tel: 01473 651704 Email: geoff.hunt@bt.com Web: www.bt.com=20 This email contains BT information, which may be privileged or confidential. It is meant only for the individual(s) or entity named above. If you are not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you have received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails.=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000=20 From geoff.hunt@bt.com Tue Dec 15 07:57:36 2009 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 D2C343A67DB for ; Tue, 15 Dec 2009 07:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 QU4ePyIwU4so for ; Tue, 15 Dec 2009 07:57:35 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 6D48F3A62C1 for ; Tue, 15 Dec 2009 07:57:35 -0800 (PST) Received: from E03MVY2-UKDY.domain1.systemhost.net ([193.113.30.58]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Dec 2009 15:57:20 +0000 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: Tue, 15 Dec 2009 15:57:19 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-shen-sipping-load-control-event-package-03 Thread-Index: Acp9n0gOqnQpKIR+Q0euCoSv60fduQ== From: To: , X-OriginalArrivalTime: 15 Dec 2009 15:57:20.0570 (UTC) FILETIME=[48A7A9A0:01CA7D9F] Subject: [sip-overload] Comments on draft-shen-sipping-load-control-event-package-03 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, 15 Dec 2009 15:57:36 -0000 Hi Charles, All, Here are some comments on the draft: 1) Section 1, para 1, typo "sever" 2) Section 4.1 Case 1 text " CPa1 then allocates the received total acceptable rate among its neighbors". Whilst CPa1 should not send more than the requested rate to EPa1, it is probably not sensible to "allocate" the total acceptable rate among its upstream neighbours, because this will (almost) guarantee it will send less than the requested rate to EPa1, because it is very likely that some sources will not offer the rate they are permitted to send. CPa1 might divide up some number larger than the total acceptable rate, to guarantee that it is able send the requested total acceptable rate to EPa1. Otherwise customer service will be worse than necessary (more calls than necessary will be rejected) and total network load will be exaggerated by unnecessary repeat attempt behaviour. 3) Section 5.7 para 2 text " then the total rate limit for the specific downstream SIP entity in the three NOTIFY messages sent to those three upstream neighbors must not exceed 100 requests per second." This is a similar comment to the comment above about section 4.1. It would be better to communicate permitted rates which *do* exceed 100 in total to upstream neighbours, and explicitly to limit downstream traffic to 100 at the local server. Otherwise the network will almost certainly be under-utilised, which is damaging to customer service. 4) Section 5.8 para 3. typo "previoulsy" 5) Section 6.3.1 para 2 last sentence, text "result is combined using logical OR". Just to clarify: does this interpretation allow joint control of traffic to a list of destinations (such as a televoting destination range) such that control does not have the effect of equalising traffic to the individual destinations? 6) Section 6.4 para 1, text " takes any one of the three sub-elements , , and " It's very hard to see how either or could make any sense for a statically-configured filtering type of control, given the uncertainty in offered traffic level and in downstream server responsiveness. 7) Section 6.4 para 2, text "The default value is "Drop" . " Will "drop" lead to retransmission by upstream elements, in networks using unreliable transport? If so this seems undesirable, by increasing load on the local device. Also 503 will allow upstream elements to re-try elsewhere which seems pointless or damaging in this type of control - would it be better to require sending 500? Hope this helps Geoff Geoff Hunt BT Design Tel: 01473 651704 Email: geoff.hunt@bt.com Web: www.bt.com=20 This email contains BT information, which may be privileged or confidential. It is meant only for the individual(s) or entity named above. If you are not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you have received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails.=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000=20 From en5192@att.com Wed Dec 23 08:19:32 2009 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 CB6693A68D1 for ; Wed, 23 Dec 2009 08:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_LIST=2.3, 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 CrCX0TrA2fm2 for ; Wed, 23 Dec 2009 08:19:32 -0800 (PST) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id E21A63A67FC for ; Wed, 23 Dec 2009 08:19:31 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: en5192@att.com X-Msg-Ref: server-3.tower-167.messagelabs.com!1261585153!13862306!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 6222 invoked from network); 23 Dec 2009 16:19:14 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Dec 2009 16:19:14 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBNGJAwc009770 for ; Wed, 23 Dec 2009 11:19:10 -0500 Received: from misout7msgusr7b.ugd.att.com (misout7msgusr7b.ugd.att.com [144.155.43.104]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBNGJ3B9009731 for ; Wed, 23 Dec 2009 11:19:03 -0500 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: Wed, 23 Dec 2009 11:19:06 -0500 Message-ID: <5DA01D2CA74FAF40ADF71DB4177D345A02685104@misout7msgusr7b.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A few comments on draft-shen-sipping-load-control-event-package-03 Thread-Index: AcqD629vEQqape05QWGHquU7KqsfRQ== From: "NOEL, ERIC C (ATTLABS)" To: Subject: [sip-overload] A few comments on draft-shen-sipping-load-control-event-package-03 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, 23 Dec 2009 16:19:32 -0000 Charles, Do you think it is possible for the specifications in draft-shen-sipping-load-control-event-package-03 to actually trigger SUBSCRIBE/NOTIFY storms? Or is that already taken care in related RFCs? For instance, if as suggested in the introduction, User Agents actually subscribe to a notifier, in a carrier grade telecommunication network this has potential for scaling problems and "large numbers" of NOTIFYs could be broadcasted towards the edges. One suggestion would be to add text in your RFC to require staggering of SUBSCRIBE/NOTIFYs over "some" time period so as to prevent message storms. In Section 4.1, similar problem could occur when entities subscribe to a notifier "when certain events have occurred". I could imagine a case where following an earthquake all User Agents within the region are programmed to subscribe to a notifier, resulting in a SUBSCRIBE/NOTIFY storm. One suggestion would be to require some randomization over time in sending SUBSCRIBEs to notifiers so as to prevent message storms. Then, is it possible for one entity to subscribe to multiple notifiers? If so, should not there be provisions against conflicting NOTIFYs from different notifiers. For instance, one notifier requests subscriber not to send any outbound traffic, while another requests not sending any inbound traffic to the same subscriber. Not sure how to deal with such a problem without requiring entities to subscribe to no more than one notifier. In general, as protection against elements or signaling failures, you probably want to require NOTIFYs to be sent no earlier than xxx days/hours/minutes prior requested action. Similarly, you probably want to limit the NOTIFY requested action to be valid for no longer than yyy days/hours/minutes. =20 There are a few typos, I assume ispell or equivalent will catch them (section 1 1st paragraph "sever", section 6.3.3 "...server depend on the type of of an initial..."). Thanks, Eric From jgunn6@csc.com Tue Dec 29 08:26:57 2009 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 957523A67D8; Tue, 29 Dec 2009 08:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, 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 fVxvaqukxb5X; Tue, 29 Dec 2009 08:26:56 -0800 (PST) Received: from mail86.messagelabs.com (mail86.messagelabs.com [216.82.242.179]) by core3.amsl.com (Postfix) with ESMTP id 07E833A65A6; Tue, 29 Dec 2009 08:26:52 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-6.tower-86.messagelabs.com!1262104003!11283374!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 6084 invoked from network); 29 Dec 2009 16:26:43 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-6.tower-86.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Dec 2009 16:26:43 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id nBTGQUFg010091; Tue, 29 Dec 2009 11:26:30 -0500 In-Reply-To: <5DA01D2CA74FAF40ADF71DB4177D345A02685104@misout7msgusr7b.ugd.att.com> References: <5DA01D2CA74FAF40ADF71DB4177D345A02685104@misout7msgusr7b.ugd.att.com> To: "NOEL, ERIC C (ATTLABS)" MIME-Version: 1.0 X-KeepSent: 6F83D839:9DB17719-8525769B:005A110A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF88 September 24, 2008 From: Janet P Gunn Message-ID: Date: Tue, 29 Dec 2009 11:26:20 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 12/29/2009 11:27:46 AM, Serialize complete at 12/29/2009 11:27:46 AM Content-Type: multipart/alternative; boundary="=_alternative 005A45D38525769B_=" Cc: sip-overload-bounces@ietf.org, sip-overload@ietf.org Subject: Re: [sip-overload] A few comments on draft-shen-sipping-load-control-event-package-03 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 Dec 2009 16:26:57 -0000 This is a multipart message in MIME format. --=_alternative 005A45D38525769B_= Content-Type: text/plain; charset="US-ASCII" I agree that it is important to make sure that any mechanism for addressing congestion does not, of itself, significantly exacerbate the congestion. Janet sip-overload-bounces@ietf.org wrote on 12/23/2009 11:19:06 AM: > [image removed] > > [sip-overload] A few comments on draft-shen-sipping-load-control- > event-package-03 > > NOEL, ERIC C (ATTLABS) > > to: > > sip-overload > > 12/23/2009 11:19 AM > > Sent by: > > sip-overload-bounces@ietf.org > > Charles, > > Do you think it is possible for the specifications in > draft-shen-sipping-load-control-event-package-03 to actually trigger > SUBSCRIBE/NOTIFY storms? Or is that already taken care in related RFCs? > > For instance, if as suggested in the introduction, User Agents actually > subscribe to a notifier, in a carrier grade telecommunication network > this has potential for scaling problems and "large numbers" of NOTIFYs > could be broadcasted towards the edges. One suggestion would be to add > text in your RFC to require staggering of SUBSCRIBE/NOTIFYs over "some" > time period so as to prevent message storms. > > In Section 4.1, similar problem could occur when entities subscribe to a > notifier "when certain events have occurred". I could imagine a case > where following an earthquake all User Agents within the region are > programmed to subscribe to a notifier, resulting in a SUBSCRIBE/NOTIFY > storm. One suggestion would be to require some randomization over time > in sending SUBSCRIBEs to notifiers so as to prevent message storms. > > Then, is it possible for one entity to subscribe to multiple notifiers? > If so, should not there be provisions against conflicting NOTIFYs from > different notifiers. For instance, one notifier requests subscriber not > to send any outbound traffic, while another requests not sending any > inbound traffic to the same subscriber. Not sure how to deal with such a > problem without requiring entities to subscribe to no more than one > notifier. > > In general, as protection against elements or signaling failures, you > probably want to require NOTIFYs to be sent no earlier than xxx > days/hours/minutes prior requested action. Similarly, you probably want > to limit the NOTIFY requested action to be valid for no longer than yyy > days/hours/minutes. > > There are a few typos, I assume ispell or equivalent will catch them > (section 1 1st paragraph "sever", section 6.3.3 "...server depend on the > type of of an initial..."). > > Thanks, > > Eric > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload --=_alternative 005A45D38525769B_= Content-Type: text/html; charset="US-ASCII"


I agree that it is important to make sure that any mechanism for addressing congestion does not, of itself, significantly exacerbate the congestion.

Janet

sip-overload-bounces@ietf.org wrote on 12/23/2009 11:19:06 AM:

> [image removed]
>
> [sip-overload] A few comments on draft-shen-sipping-load-control-
> event-package-03
>
> NOEL, ERIC C (ATTLABS)
>
> to:
>
> sip-overload
>
> 12/23/2009 11:19 AM
>
> Sent by:
>
> sip-overload-bounces@ietf.org
>
> Charles,
>
> Do you think it is possible for the specifications in
> draft-shen-sipping-load-control-event-package-03 to actually trigger
> SUBSCRIBE/NOTIFY storms? Or is that already taken care in related RFCs?
>
> For instance, if as suggested in the introduction, User Agents actually
> subscribe to a notifier, in a carrier grade telecommunication network
> this has potential for scaling problems and "large numbers" of NOTIFYs
> could be broadcasted towards the edges. One suggestion would be to add
> text in your RFC to require staggering of SUBSCRIBE/NOTIFYs over "some"
> time period so as to prevent message storms.
>
> In Section 4.1, similar problem could occur when entities subscribe to a
> notifier "when certain events have occurred". I could imagine a case
> where following an earthquake all User Agents within the region are
> programmed to subscribe to a notifier, resulting in a SUBSCRIBE/NOTIFY
> storm. One suggestion would be to require some randomization over time
> in sending SUBSCRIBEs to notifiers so as to prevent message storms.
>
> Then, is it possible for one entity to subscribe to multiple notifiers?
> If so, should not there be provisions against conflicting NOTIFYs from
> different notifiers. For instance, one notifier requests subscriber not
> to send any outbound traffic, while another requests not sending any
> inbound traffic to the same subscriber. Not sure how to deal with such a
> problem without requiring entities to subscribe to no more than one
> notifier.
>
> In general, as protection against elements or signaling failures, you
> probably want to require NOTIFYs to be sent no earlier than xxx
> days/hours/minutes prior requested action. Similarly, you probably want
> to limit the NOTIFY requested action to be valid for no longer than yyy
> days/hours/minutes.  
>
> There are a few typos, I assume ispell or equivalent will catch them
> (section 1 1st paragraph "sever", section 6.3.3 "...server depend on the
> type of of an initial...").
>
> Thanks,
>
> Eric
>
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
 --=_alternative 005A45D38525769B_=-- From jgunn6@csc.com Tue Dec 29 13:41:50 2009 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 2AE423A6911; Tue, 29 Dec 2009 13:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.215 X-Spam-Level: X-Spam-Status: No, score=-6.215 tagged_above=-999 required=5 tests=[AWL=0.383, 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 vwc28F59JsOV; Tue, 29 Dec 2009 13:41:49 -0800 (PST) Received: from mail64.messagelabs.com (mail64.messagelabs.com [216.82.249.227]) by core3.amsl.com (Postfix) with ESMTP id D45043A68A5; Tue, 29 Dec 2009 13:41:48 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-2.tower-64.messagelabs.com!1262122887!8047585!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 19772 invoked from network); 29 Dec 2009 21:41:28 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-2.tower-64.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Dec 2009 21:41:28 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id nBTLfEa3027410; Tue, 29 Dec 2009 16:41:16 -0500 In-Reply-To: References: To: Charles Shen MIME-Version: 1.0 X-KeepSent: 37A04954:3550493E-8525769B:0076FB2C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF88 September 24, 2008 From: Janet P Gunn Message-ID: Date: Tue, 29 Dec 2009 16:41:22 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 12/29/2009 04:42:42 PM, Serialize complete at 12/29/2009 04:42:42 PM Content-Type: multipart/alternative; boundary="=_alternative 00772B288525769B_=" Cc: sip-overload-bounces@ietf.org, sip-overload@ietf.org, Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] Fwd: draft-shen-sipping-avalanche-restart-overload-00 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 Dec 2009 21:41:50 -0000 This is a multipart message in MIME format. --=_alternative 00772B288525769B_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSBoYXZlIGFuIG92ZXJhbGwgY29uY2VybiBmb3IgdGhpcyBkcmFmdCBpbiB0aGF0IGl0IGF0dGVt cHRzIHRvIGZpbmQgYSANCnNvbHV0aW9uIGZvciBhIHNwZWNpZmljIHNpdHVhdGlvbiwgd2l0aG91 dCBzdWZmaWNpZW50bHkgYWRkcmVzc2luZyB0aGUgDQoobmVnYXRpdmUpIHVuaW50ZW5kZWQgY29u c2VxdWVuY2VzIGluIGEgdmFyaWV0eSBvZiBvdGhlciBzaXR1YXRpb25zLg0KDQpUaGUgYmFzaWMg cHJvYmxlbSBpcyB0aGF0IHRoZSBiZWhhdmlvciB3aGljaCBoZWxwcyBpbiBhbiDigJxhdmFsYW5j aGUgDQpyZXN0YXJ04oCdIHNjZW5hcmlvIGlzICDigJxiYWQgZm9yIGJ1c2luZXNz4oCdIGluIGEg d2lkZSB2YXJpZXR5IG9mIG90aGVyIA0KcmVzdGFydCBzY2VuYXJpb3MsIGFuZCBpdCBpcyBoaWdo bHkgdW5saWtlbHkgdGhhdCBlaXRoZXIgdGhlIHVzZXIgb3IgdGhlIA0KdXNlciBhZ2VudCBjYW4g ZGV0ZXJtaW5lIHdoaWNoIGlzIHdoaWNoLg0KRm9yIGluc3RhbmNlLCB0aGUg4oCcZXhhbXBsZeKA nSBpbiBzZWN0aW9uIDMuMSBzdWdnZXN0cyB0aGF0IDMwMCBzZWNvbmRzICg1IA0KbWludXRlcykg aXMgYSByZWFzb25hYmxlIHZhbHVlIGZvciB0aGUgcmVzdGFydCBiYWNrb2ZmIGludGVydmFsICh0 aHVzIHRoZSANCmF2ZXJhZ2UgYmFja29mZiB3b3VsZCBiZSAyLjUgbWludXRlcykuDQpUaGlzIGlz IGVudGlyZWx5IHBsYXVzaWJsZSBmb3IgYW4g4oCcYXZhbGFuY2hlIHJlc3RhcnTigJ0gZXZlbnQu ICBCdXQgSSBkb27igJl0IA0KdGhpbmsgaXQgd2lsbCBiZSBhY2NlcHRhYmxlLCB0byBlaXRoZXIg dGhlIHVzZXJzIG9yIHRoZSBTZXJ2aWNlIFByb3ZpZGVycywgDQpldmVyeSB0aW1lIGEgbW9iaWxl IFVzZXIgQWdlbnQgbmVlZHMgdG8gcmVnaXN0ZXIgZHVlIHRvIGEg4oCccG93ZXIgb2ZmIA0KcmVj b3ZlcnnigJ0gb3IgYSDigJxjb25uZWN0aW9uIGxvc3MgcmVjb3ZlcnnigJ0uIA0KVGhlIGRyYWZ0 IHN1Z2dlc3RzIHRoYXQgdGhlIGNsaWVudCBzaWRlIGJhY2tvZmYgTUFZIGJlIGRpc2FibGVkIGJ5 ICB0aGUgDQpodW1hbiBvcGVyYXRvci4gIEJ1dCwgaW4gdGhlIHZhc3QgbWFqb3JpdHkgb2YgY2Fz ZXMsIHRoZSBodW1hbiBvcGVyYXRvciANCmhhcyBubyB3YXkgb2Yga25vd2luZyB3aGV0aGVyIGl0 IGlzIGFuIGlzb2xhdGVkIHJlIHJlZ2lzdGVyIG9yIGFuIA0KYXZhbGFuY2hlIGV2ZW50LiAgIEkg c3VzcGVjdCB0aGF0IHRoZSB2YXN0IG1ham9yaXR5IG9mIHVzZXJzIHdvdWxkIGJlIA0Kb2JsaXZp b3VzLCBhbmQgbmV2ZXIgZGlzYWJsZSBpdCwgYW5kIHRoYXQgdGhlIG1vcmUgc29waGlzdGljYXRl ZCB1c2VycywgDQp3aG8ga25vdyBhYm91dCBpdCwgd291bGQgYWx3YXlzIGRpc2FibGUgaXQuICBF dmVuIHRoZSBrbm93bGVkZ2VhYmxlIGJ1dCANCmNvbnNpZGVyYXRlIHVzZXIgaXMgdW5saWtlbHkg dG8ga25vdyB3aGV0aGVyIHRoaXMgaXMgYSBsb2NhbCwg4oCcb25seSBtZeKAnSANCnJlLWNvbm5l Y3Rpb24sIG9yIGFuIGF2YWxhbmNoZS4NClRoZSBTZXJ2aWNlIHByb3ZpZGVycyBhcmUgdW5saWtl bHkgdG8gYmUgd2lsbGluZyB0byBzYWNyaWZpY2UgYW4gYXZlcmFnZSANCm9mIDE1MCBzZWNvbmRz IG9mIHBvdGVudGlhbGx5IGJpbGxhYmxlIGNhbGxzICBvbiBldmVyeSBwb3dlciB1cCBvciANCmNv bm5lY3Rpb24gcmUtZXN0YWJsaXNobWVudC4gIEFuZCBpZiBpdCBwcm92aWRlZCBhIHJpdmFsICBT ZXJ2aWNlIFByb3ZpZGVyIA0KdGhlIG9wcG9ydHVuaXR5IHRvICBvZmZlciAg4oCcVXAgdG8gMzAw IHNlY29uZHMgZmFzdGVyIGluaXRpYWwgY29ubmVjdGlvbuKAnSANCnRoZSBtYXJrZXRpbmcgZGVw YXJ0bWVudCB3b3VsZCBuZXZlciBwZXJtaXQgaXQuDQpBIG5vYmxlIGF0dGVtcHQgdG8gYWRkcmVz cyBhIHJlYWwgcHJvYmxlbSwgYnV0IEkgZmVhciBpdCBpcyBkZWZlYXRlZCBieSANCnRoZSBkZXZp bCBvZiDigJx1bmludGVuZGVkIGNvbnNlcXVlbmNlc+KAnQ0KSmFuZXQNCg0Kc2lwLW92ZXJsb2Fk LWJvdW5jZXNAaWV0Zi5vcmcgd3JvdGUgb24gMTIvMDMvMjAwOSAwOTozMToxMSBBTToNCg0KPiBD aGFybGVzIFNoZW4gPGNoYXJsZXNAY3MuY29sdW1iaWEuZWR1PiANCj4gU2VudCBieTogc2lwLW92 ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmcNCj4gDQo+IDEyLzAzLzIwMDkgMDk6MzEgQU0NCj4gDQo+ IFRvDQo+IA0KPiBzaXAtb3ZlcmxvYWRAaWV0Zi5vcmcNCj4gDQo+IGNjDQo+IA0KPiBBcmF0YSBL b2lrZSA8a29pa2UuYXJhdGFAbGFiLm50dC5jby5qcD4sIEhlbm5pbmcgU2NodWx6cmlubmUgDQo+ IDxoZ3NAY3MuY29sdW1iaWEuZWR1Pg0KPiANCj4gU3ViamVjdA0KPiANCj4gW3NpcC1vdmVybG9h ZF0gRndkOiBkcmFmdC1zaGVuLXNpcHBpbmctYXZhbGFuY2hlLXJlc3RhcnQtb3ZlcmxvYWQtMDAN Cj4gDQo+IEhpIGFsbCwgd2UndmUgc3VibWl0dGVkIHRoZSBmb2xsb3dpbmcgZHJhZnQsIGNvbW1l bnRzIGFwcHJlY2lhdGVkLg0KPiANCj4gQSBNZWNoYW5pc20gZm9yIFNlc3Npb24gSW5pdGlhdGlv biBQcm90b2NvbCAoU0lQKSBBdmFsYW5jaGUgUmVzdGFydA0KPiBPdmVybG9hZCBDb250cm9sDQo+ IA0KPiANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNoZW4tc2lwcGluZy1hdmFs YW5jaGUtcmVzdGFydC1vdmVybG9hZC0wMA0KDQo+IA0KPiBBYnN0cmFjdA0KPiANCj4gICBXaGVu IGEgbGFyZ2UgbnVtYmVyIG9mIGNsaWVudHMgcmVnaXN0ZXIgd2l0aCBhIFNJUCByZWdpc3RyYXIg c2VydmVyDQo+ICAgYXQgYXBwcm94aW1hdGVseSB0aGUgc2FtZSB0aW1lLCB0aGUgc2VydmVyIG1h eSBiZWNvbWUgb3ZlcmxvYWRlZC4NCj4gICBOZWFyLXNpbXVsdGFuZW91cyBmbG9vZHMgb2YgU0lQ IFNVQlNDUklCRSBhbmQgUFVCTElTSCByZXF1ZXN0cyBtYXkNCj4gICBoYXZlIHNpbWlsYXIgZWZm ZWN0cy4gIFN1Y2ggcmVxdWVzdCBhdmFsYW5jaGVzIGNhbiBvY2N1ciwgZm9yDQo+ICAgZXhhbXBs ZSwgYWZ0ZXIgYSBwb3dlciBmYWlsdXJlIGFuZCByZWNvdmVyeSBpbiBhIG1ldHJvcG9saXRhbiBh cmVhLg0KPiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0byBhdm9pZCBzdWNoIG92ZXJs b2FkIHNpdHVhdGlvbnMuICBVbmRlcg0KPiAgIHRoaXMgbWVjaGFuaXNtLCBhIHNlcnZlciBlc3Rp bWF0ZXMgYW4gYXZhbGFuY2hlIHJlc3RhcnQgYmFja29mZg0KPiAgIGludGVydmFsIGR1cmluZyBp dHMgbm9ybWFsIG9wZXJhdGlvbiBhbmQgY29udmV5cyB0aGlzIGludGVydmFsIHRvIGl0cw0KPiAg IGNsaWVudHMgdGhyb3VnaCBhIG5ldyBSZWdpc3Rlci1SZXN0YXJ0IGhlYWRlciBpbiByZWdpc3Ry YXRpb24NCj4gICByZXNwb25zZXMuICBPbmNlIGFuIGF2YWxhbmNoZSByZXN0YXJ0IGFjdHVhbGx5 IG9jY3VycywgdGhlIGNsaWVudHMNCj4gICBwZXJmb3JtIGJhY2tvZmYgYmFzZWQgb24gdGhlIHBy ZXZpb3VzbHkgcmVjZWl2ZWQgUmVnaXN0ZXItUmVzdGFydA0KPiAgIGhlYWRlciB2YWx1ZSBiZWZv cmUgc2VuZGluZyBvdXQgdGhlIGZpcnN0IHJlZ2lzdHJhdGlvbiBhdHRlbXB0Lg0KPiAgIFRodXMs IHRoZSBtZWNoYW5pc20gc3ByZWFkcyBhbGwgdGhlIGluaXRpYWwgY2xpZW50IHJlZ2lzdHJhdGlv bg0KPiAgIHJlcXVlc3RzIGFuZCBwcmV2ZW50cyB0aGVtIGZyb20gb3ZlcmxvYWRpbmcgdGhlIHJl Z2lzdHJhciBzZXJ2ZXIuDQo+IA0KPiANCj4gVGhhbmtzDQo+IA0KPiBDaGFybGVzDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNpcC1vdmVybG9h ZCBtYWlsaW5nIGxpc3QNCj4gc2lwLW92ZXJsb2FkQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwLW92ZXJsb2FkDQoNCg== --=_alternative 00772B288525769B_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+SSBoYXZlIGFuIG92ZXJhbGwgY29uY2VybiBmb3IgdGhpcyBk cmFmdA0KaW4gdGhhdCBpdCBhdHRlbXB0cyB0byBmaW5kIGEgc29sdXRpb24gZm9yIGEgc3BlY2lm aWMgc2l0dWF0aW9uLCB3aXRob3V0DQpzdWZmaWNpZW50bHkgYWRkcmVzc2luZyB0aGUgKG5lZ2F0 aXZlKSB1bmludGVuZGVkIGNvbnNlcXVlbmNlcyBpbiBhIHZhcmlldHkNCm9mIG90aGVyIHNpdHVh dGlvbnMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5UaGUg YmFzaWMgcHJvYmxlbSBpcyB0aGF0IHRoZSBiZWhhdmlvcg0Kd2hpY2ggaGVscHMgaW4gYW4g4oCc YXZhbGFuY2hlIHJlc3RhcnTigJ0gc2NlbmFyaW8gaXMgJm5ic3A74oCcYmFkIGZvciBidXNpbmVz c+KAnQ0KaW4gYSB3aWRlIHZhcmlldHkgb2Ygb3RoZXIgcmVzdGFydCBzY2VuYXJpb3MsIGFuZCBp dCBpcyBoaWdobHkgdW5saWtlbHkNCnRoYXQgZWl0aGVyIHRoZSB1c2VyIG9yIHRoZSB1c2VyIGFn ZW50IGNhbiBkZXRlcm1pbmUgd2hpY2ggaXMgd2hpY2guPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0y IGZhY2U9IkNhbGlicmkiPkZvciBpbnN0YW5jZSwgdGhlIOKAnGV4YW1wbGXigJ0gaW4gc2VjdGlv bg0KMy4xIHN1Z2dlc3RzIHRoYXQgMzAwIHNlY29uZHMgKDUgbWludXRlcykgaXMgYSByZWFzb25h YmxlIHZhbHVlIGZvciB0aGUNCnJlc3RhcnQgYmFja29mZiBpbnRlcnZhbCAodGh1cyB0aGUgYXZl cmFnZSBiYWNrb2ZmIHdvdWxkIGJlIDIuNSBtaW51dGVzKS48L2ZvbnQ+DQo8cD48Zm9udCBzaXpl PTIgZmFjZT0iQ2FsaWJyaSI+VGhpcyBpcyBlbnRpcmVseSBwbGF1c2libGUgZm9yIGFuIOKAnGF2 YWxhbmNoZQ0KcmVzdGFydOKAnSBldmVudC4gJm5ic3A7QnV0IEkgZG9u4oCZdCB0aGluayBpdCB3 aWxsIGJlIGFjY2VwdGFibGUsIHRvIGVpdGhlcg0KdGhlIHVzZXJzIG9yIHRoZSBTZXJ2aWNlIFBy b3ZpZGVycywgZXZlcnkgdGltZSBhIG1vYmlsZSBVc2VyIEFnZW50IG5lZWRzDQp0byByZWdpc3Rl ciBkdWUgdG8gYSDigJxwb3dlciBvZmYgcmVjb3ZlcnnigJ0gb3IgYSDigJxjb25uZWN0aW9uIGxv c3MgcmVjb3ZlcnnigJ0uDQombmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ2Fs aWJyaSI+VGhlIGRyYWZ0IHN1Z2dlc3RzIHRoYXQgdGhlIGNsaWVudCBzaWRlDQpiYWNrb2ZmIE1B WSBiZSBkaXNhYmxlZCBieSAmbmJzcDt0aGUgaHVtYW4gb3BlcmF0b3IuICZuYnNwO0J1dCwgaW4g dGhlDQp2YXN0IG1ham9yaXR5IG9mIGNhc2VzLCB0aGUgaHVtYW4gb3BlcmF0b3IgaGFzIG5vIHdh eSBvZiBrbm93aW5nIHdoZXRoZXINCml0IGlzIGFuIGlzb2xhdGVkIHJlIHJlZ2lzdGVyIG9yIGFu IGF2YWxhbmNoZSBldmVudC4gJm5ic3A7IEkgc3VzcGVjdCB0aGF0DQp0aGUgdmFzdCBtYWpvcml0 eSBvZiB1c2VycyB3b3VsZCBiZSBvYmxpdmlvdXMsIGFuZCBuZXZlciBkaXNhYmxlIGl0LCBhbmQN CnRoYXQgdGhlIG1vcmUgc29waGlzdGljYXRlZCB1c2Vycywgd2hvIGtub3cgYWJvdXQgaXQsIHdv dWxkIGFsd2F5cyBkaXNhYmxlDQppdC4gJm5ic3A7RXZlbiB0aGUga25vd2xlZGdlYWJsZSBidXQg Y29uc2lkZXJhdGUgdXNlciBpcyB1bmxpa2VseSB0byBrbm93DQp3aGV0aGVyIHRoaXMgaXMgYSBs b2NhbCwg4oCcb25seSBtZeKAnSByZS1jb25uZWN0aW9uLCBvciBhbiBhdmFsYW5jaGUuPC9mb250 Pg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlRoZSBTZXJ2aWNlIHByb3ZpZGVycyBh cmUgdW5saWtlbHkgdG8gYmUNCndpbGxpbmcgdG8gc2FjcmlmaWNlIGFuIGF2ZXJhZ2Ugb2YgMTUw IHNlY29uZHMgb2YgcG90ZW50aWFsbHkgYmlsbGFibGUNCmNhbGxzICZuYnNwO29uIGV2ZXJ5IHBv d2VyIHVwIG9yIGNvbm5lY3Rpb24gcmUtZXN0YWJsaXNobWVudC4gJm5ic3A7QW5kDQppZiBpdCBw cm92aWRlZCBhIHJpdmFsICZuYnNwO1NlcnZpY2UgUHJvdmlkZXIgdGhlIG9wcG9ydHVuaXR5IHRv ICZuYnNwO29mZmVyDQombmJzcDvigJxVcCB0byAzMDAgc2Vjb25kcyBmYXN0ZXIgaW5pdGlhbCBj b25uZWN0aW9u4oCdIHRoZSBtYXJrZXRpbmcgZGVwYXJ0bWVudA0Kd291bGQgbmV2ZXIgcGVybWl0 IGl0LjwvZm9udD4NCjxwPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5BIG5vYmxlIGF0dGVt cHQgdG8gYWRkcmVzcyBhIHJlYWwgcHJvYmxlbSwNCmJ1dCBJIGZlYXIgaXQgaXMgZGVmZWF0ZWQg YnkgdGhlIGRldmlsIG9mIOKAnHVuaW50ZW5kZWQgY29uc2VxdWVuY2Vz4oCdPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkphbmV0PC9mb250Pg0KPGJyPg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmcgd3JvdGUgb24gMTIv MDMvMjAwOQ0KMDk6MzE6MTEgQU06PGJyPg0KPGJyPg0KJmd0OyBDaGFybGVzIFNoZW4gJmx0O2No YXJsZXNAY3MuY29sdW1iaWEuZWR1Jmd0OyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgU2VudCBieTogc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmc8YnI+DQomZ3Q7 IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAxMi8wMy8yMDA5IDA5OjMx IEFNPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgVG88 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBzaXAtb3Zl cmxvYWRAaWV0Zi5vcmc8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJy Pg0KJmd0OyBjYzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQom Z3Q7IEFyYXRhIEtvaWtlICZsdDtrb2lrZS5hcmF0YUBsYWIubnR0LmNvLmpwJmd0OywgSGVubmlu ZyBTY2h1bHpyaW5uZQ0KPGJyPg0KJmd0OyAmbHQ7aGdzQGNzLmNvbHVtYmlhLmVkdSZndDs8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBTdWJqZWN0PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgW3NpcC1vdmVy bG9hZF0gRndkOiBkcmFmdC1zaGVuLXNpcHBpbmctYXZhbGFuY2hlLXJlc3RhcnQtb3ZlcmxvYWQt MDA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBIaSBh bGwsIHdlJ3ZlIHN1Ym1pdHRlZCB0aGUgZm9sbG93aW5nIGRyYWZ0LCBjb21tZW50cyBhcHByZWNp YXRlZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgQSBNZWNoYW5pc20gZm9yIFNlc3Npb24gSW5pdGlh dGlvbiBQcm90b2NvbCAoU0lQKSBBdmFsYW5jaGUgUmVzdGFydDxicj4NCiZndDsgT3ZlcmxvYWQg Q29udHJvbDxicj4NCiZndDsgPGJyPg0KJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaGVuLXNpcHBpbmctYXZhbGFuY2hlLXJlc3RhcnQt b3ZlcmxvYWQtMDAiPjx0dD48Zm9udCBzaXplPTI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtc2hlbi1zaXBwaW5nLWF2YWxhbmNoZS1yZXN0YXJ0LW92ZXJsb2FkLTAwPC9mb250Pjwv dHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFic3RyYWN0PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyBXaGVuIGEgbGFyZ2UgbnVtYmVyIG9mIGNsaWVudHMg cmVnaXN0ZXIgd2l0aCBhIFNJUCByZWdpc3RyYXINCnNlcnZlcjxicj4NCiZndDsgJm5ic3A7IGF0 IGFwcHJveGltYXRlbHkgdGhlIHNhbWUgdGltZSwgdGhlIHNlcnZlciBtYXkgYmVjb21lIG92ZXJs b2FkZWQuPGJyPg0KJmd0OyAmbmJzcDsgTmVhci1zaW11bHRhbmVvdXMgZmxvb2RzIG9mIFNJUCBT VUJTQ1JJQkUgYW5kIFBVQkxJU0ggcmVxdWVzdHMNCm1heTxicj4NCiZndDsgJm5ic3A7IGhhdmUg c2ltaWxhciBlZmZlY3RzLiAmbmJzcDtTdWNoIHJlcXVlc3QgYXZhbGFuY2hlcyBjYW4gb2NjdXIs DQpmb3I8YnI+DQomZ3Q7ICZuYnNwOyBleGFtcGxlLCBhZnRlciBhIHBvd2VyIGZhaWx1cmUgYW5k IHJlY292ZXJ5IGluIGEgbWV0cm9wb2xpdGFuDQphcmVhLjxicj4NCiZndDsgJm5ic3A7IFRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0byBhdm9pZCBzdWNoIG92ZXJsb2FkIHNpdHVhdGlvbnMu DQombmJzcDtVbmRlcjxicj4NCiZndDsgJm5ic3A7IHRoaXMgbWVjaGFuaXNtLCBhIHNlcnZlciBl c3RpbWF0ZXMgYW4gYXZhbGFuY2hlIHJlc3RhcnQgYmFja29mZjxicj4NCiZndDsgJm5ic3A7IGlu dGVydmFsIGR1cmluZyBpdHMgbm9ybWFsIG9wZXJhdGlvbiBhbmQgY29udmV5cyB0aGlzIGludGVy dmFsDQp0byBpdHM8YnI+DQomZ3Q7ICZuYnNwOyBjbGllbnRzIHRocm91Z2ggYSBuZXcgUmVnaXN0 ZXItUmVzdGFydCBoZWFkZXIgaW4gcmVnaXN0cmF0aW9uPGJyPg0KJmd0OyAmbmJzcDsgcmVzcG9u c2VzLiAmbmJzcDtPbmNlIGFuIGF2YWxhbmNoZSByZXN0YXJ0IGFjdHVhbGx5IG9jY3VycywNCnRo ZSBjbGllbnRzPGJyPg0KJmd0OyAmbmJzcDsgcGVyZm9ybSBiYWNrb2ZmIGJhc2VkIG9uIHRoZSBw cmV2aW91c2x5IHJlY2VpdmVkIFJlZ2lzdGVyLVJlc3RhcnQ8YnI+DQomZ3Q7ICZuYnNwOyBoZWFk ZXIgdmFsdWUgYmVmb3JlIHNlbmRpbmcgb3V0IHRoZSBmaXJzdCByZWdpc3RyYXRpb24gYXR0ZW1w dC48YnI+DQomZ3Q7ICZuYnNwOyBUaHVzLCB0aGUgbWVjaGFuaXNtIHNwcmVhZHMgYWxsIHRoZSBp bml0aWFsIGNsaWVudCByZWdpc3RyYXRpb248YnI+DQomZ3Q7ICZuYnNwOyByZXF1ZXN0cyBhbmQg cHJldmVudHMgdGhlbSBmcm9tIG92ZXJsb2FkaW5nIHRoZSByZWdpc3RyYXIgc2VydmVyLjxicj4N CiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rczxicj4NCiZndDsgPGJyPg0KJmd0OyBD aGFybGVzPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCiZndDsgc2lwLW92ZXJsb2FkIG1haWxpbmcgbGlzdDxicj4NCiZndDsgc2lw LW92ZXJsb2FkQGlldGYub3JnPGJyPg0KJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZCI+PHR0Pjxmb250IHNp emU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZDwv Zm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwvZm9udD48L3R0Pg0K --=_alternative 00772B288525769B_=-- From jgunn6@csc.com Tue Dec 29 14:25:28 2009 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 51E4F3A69F2; Tue, 29 Dec 2009 14:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.711 X-Spam-Level: X-Spam-Status: No, score=-5.711 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_74=0.6, 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 MU0fUizBA78M; Tue, 29 Dec 2009 14:25:26 -0800 (PST) Received: from mail168.messagelabs.com (mail168.messagelabs.com [216.82.253.195]) by core3.amsl.com (Postfix) with ESMTP id 7CF283A69ED; Tue, 29 Dec 2009 14:25:26 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-6.tower-168.messagelabs.com!1262125503!12971384!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 20685 invoked from network); 29 Dec 2009 22:25:04 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-6.tower-168.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Dec 2009 22:25:04 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id nBTMP2Dk029538; Tue, 29 Dec 2009 17:25:03 -0500 In-Reply-To: References: To: MIME-Version: 1.0 X-KeepSent: 30F03E3F:A240DD8B-8525769B:0077DA82; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF88 September 24, 2008 From: Janet P Gunn Message-ID: Date: Tue, 29 Dec 2009 17:24:57 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 12/29/2009 05:26:19 PM, Serialize complete at 12/29/2009 05:26:19 PM Content-Type: multipart/alternative; boundary="=_alternative 007B28888525769B_=" Cc: sip-overload-bounces@ietf.org, charles@cs.columbia.edu, sip-overload@ietf.org Subject: Re: [sip-overload] Comments on draft-shen-sipping-load-control-event-package-03 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 Dec 2009 22:25:28 -0000 This is a multipart message in MIME format. --=_alternative 007B28888525769B_= Content-Type: text/plain; charset="US-ASCII" I completely agree with point number two. When you are invoking a control analogous to "cancel to- call gapping", there is absolutely no assurance that the sources of the load to the specific destination will be evenly distributed among the neighbors. If you are going to propagate a "cancel to-call gapping"load control, the sensible thing would be to give EVERY neighbor the full permitted rate. (note that this is a problem with the example, and not necessarily with the underlying mechanism) In case II of section 4.1, I sincerely doubt that CPb2, EPb3 and EPb4 "configure themselves" They will be manually configured under the guidance of the same people who have determined that "outgoing calls are more important than incoming calls". That is just semantics'. But I am having difficulty following how (or why) this is propagated to other servers beyond the direct neighbors. CPb1 and CPa2 can be instructed to reduce the rate at which they send calls to CPb2. But how is CPa1 (or any of the EPax) to know which calls it needs to suppress? To follow on the same theme. in section 4.2, I understand how you can limit SIP messages based on "callee number" (aka destination URI). but I fail to see how a "wildcard domain based filter" can identify SIP messages destined for CPb2. I also agree with comments 3 and 6. There is a good reason why "percent blocking" has largely been replaced with "call gapping" (aka rate based) load controls in the circuit switched world, and the same logic applies here. Janet sip-overload-bounces@ietf.org wrote on 12/15/2009 10:57:19 AM: > > Sent by: sip-overload-bounces@ietf.org > > 12/15/2009 10:57 AM > > To > > , > > cc > > Subject > > [sip-overload] Comments on draft-shen-sipping-load-control-event-package-03 > > Hi Charles, All, > > Here are some comments on the draft: > > 1) Section 1, para 1, typo "sever" > > 2) Section 4.1 Case 1 text " CPa1 then allocates the received total > acceptable rate among its neighbors". Whilst CPa1 should not send more > than the requested rate to EPa1, it is probably not sensible to > "allocate" the total acceptable rate among its upstream neighbours, > because this will (almost) guarantee it will send less than the > requested rate to EPa1, because it is very likely that some sources will > not offer the rate they are permitted to send. CPa1 might divide up some > number larger than the total acceptable rate, to guarantee that it is > able send the requested total acceptable rate to EPa1. Otherwise > customer service will be worse than necessary (more calls than necessary > will be rejected) and total network load will be exaggerated by > unnecessary repeat attempt behaviour. > > 3) Section 5.7 para 2 text " then the total rate limit for the specific > downstream SIP entity in the three NOTIFY messages sent to those three > upstream neighbors must not exceed 100 requests per second." This is a > similar comment to the comment above about section 4.1. It would be > better to communicate permitted rates which *do* exceed 100 in total to > upstream neighbours, and explicitly to limit downstream traffic to 100 > at the local server. Otherwise the network will almost certainly be > under-utilised, which is damaging to customer service. > > 4) Section 5.8 para 3. typo "previoulsy" > > 5) Section 6.3.1 para 2 last sentence, text "result is combined using > logical OR". Just to clarify: does this interpretation allow joint > control of traffic to a list of destinations (such as a televoting > destination range) such that control does not have the effect of > equalising traffic to the individual destinations? > > 6) Section 6.4 para 1, text " takes any one of the three sub-elements > , , and " It's very hard to see how either > or could make any sense for a statically-configured filtering type > of control, given the uncertainty in offered traffic level and in > downstream server responsiveness. > > 7) Section 6.4 para 2, text "The default value is "Drop" . " Will > "drop" lead to retransmission by upstream elements, in networks using > unreliable transport? If so this seems undesirable, by increasing load > on the local device. Also 503 will allow upstream elements to re-try > elsewhere which seems pointless or damaging in this type of control - > would it be better to require sending 500? > > Hope this helps > > Geoff > > Geoff Hunt > BT Design > > Tel: 01473 651704 > Email: geoff.hunt@bt.com > Web: www.bt.com > This email contains BT information, which may be privileged or > confidential. > It is meant only for the individual(s) or entity named above. If you are > not the intended > recipient, note that disclosing, copying, distributing or using this > information > is prohibited. If you have received this email in error, please let me > know immediately > on the email address above. Thank you. > We monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload --=_alternative 007B28888525769B_= Content-Type: text/html; charset="US-ASCII"
I completely agree with point number two.  When you are invoking a control analogous to "cancel to- call gapping", there is absolutely no assurance that the sources of the load to the specific destination will be evenly distributed among the neighbors.  If you are going to propagate a "cancel to-call gapping"load control, the sensible thing would be to give EVERY neighbor the full permitted rate. (note that this is a problem with the example, and not necessarily with the underlying mechanism)

In case II of section 4.1, I  sincerely doubt that CPb2, EPb3 and EPb4 "configure themselves"  They will be manually configured under the guidance of the same people who have determined that "outgoing calls are more important than incoming calls". That is just semantics'.  But I am having difficulty following how (or why) this is propagated to other servers beyond the direct neighbors.  CPb1 and CPa2 can be instructed to reduce the rate at which they send calls to CPb2.   But how is CPa1 (or any of the EPax)  to know which calls it needs to suppress?

To follow on the same theme. in section 4.2, I understand how you can limit SIP messages based on "callee number" (aka destination URI).  but I fail to see how a "wildcard domain based filter" can identify SIP messages destined for CPb2.

I also agree with comments 3 and 6.  There is a good reason why "percent blocking" has largely been replaced with "call gapping" (aka rate based) load controls in the circuit switched world, and the same logic applies here.

Janet
sip-overload-bounces@ietf.org wrote on 12/15/2009 10:57:19 AM:

> <geoff.hunt@bt.com>
> Sent by: sip-overload-bounces@ietf.org
>
> 12/15/2009 10:57 AM
>
> To
>
> <charles@cs.columbia.edu>, <sip-overload@ietf.org>
>
> cc
>
> Subject
>
> [sip-overload] Comments on draft-shen-sipping-load-control-event-package-03
>
> Hi Charles, All,
>
> Here are some comments on the draft:
>
> 1) Section 1, para 1, typo "sever"
>
> 2) Section 4.1 Case 1 text " CPa1 then allocates the received total
> acceptable rate among its neighbors". Whilst CPa1 should not send more
> than the requested rate to EPa1, it is probably not sensible to
> "allocate" the total acceptable rate among its upstream neighbours,
> because this will (almost) guarantee it will send less than the
> requested rate to EPa1, because it is very likely that some sources will
> not offer the rate they are permitted to send. CPa1 might divide up some
> number larger than the total acceptable rate, to guarantee that it is
> able send the requested total acceptable rate to EPa1. Otherwise
> customer service will be worse than necessary (more calls than necessary
> will be rejected) and total network load will be exaggerated by
> unnecessary repeat attempt behaviour.
>
> 3) Section 5.7 para 2 text " then the total rate limit for the specific
> downstream SIP entity in the three NOTIFY messages sent to those three
> upstream neighbors must not exceed  100 requests per second." This is a
> similar comment to the comment above about section 4.1. It would be
> better to communicate permitted rates which *do* exceed 100 in total to
> upstream neighbours, and explicitly to limit downstream traffic to 100
> at the local server. Otherwise the network will almost certainly be
> under-utilised, which is damaging to customer service.
>
> 4) Section 5.8 para 3. typo "previoulsy"
>
> 5) Section 6.3.1 para 2 last sentence, text "result is combined using
> logical OR". Just to clarify: does this interpretation allow joint
> control of traffic to a list of destinations (such as a televoting
> destination range) such that control does not have the effect of
> equalising traffic to the individual destinations?
>
> 6) Section 6.4 para 1, text " takes any one of the three sub-elements
> <rate>, <percent>, and <win>" It's very hard to see how either <percent>
> or <win> could make any sense for a statically-configured filtering type
> of control, given the uncertainty in offered traffic level and in
> downstream server responsiveness.
>
> 7) Section 6.4 para 2, text "The default value is "Drop" .  " Will
> "drop" lead to retransmission by upstream elements, in networks using
> unreliable transport? If so this seems undesirable, by increasing load
> on the local device. Also 503 will allow upstream elements to re-try
> elsewhere which seems pointless or damaging in this type of control -
> would it be better to require sending 500?
>
> Hope this helps
>
> Geoff
>
> Geoff Hunt
> BT Design
>
> Tel: 01473 651704
> Email: geoff.hunt@bt.com
> Web: www.bt.com
> This email contains BT information, which may be privileged or
> confidential.
> It is meant only for the individual(s) or entity named above. If you are
> not the intended
> recipient, note that disclosing, copying, distributing or using this
> information
> is prohibited. If you have received this email in error, please let me
> know immediately
> on the email address above. Thank you.
> We monitor our email system, and may record your emails.
> British Telecommunications plc
> Registered office: 81 Newgate Street London EC1A 7AJ
> Registered in England no: 1800000
>
>
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
 --=_alternative 007B28888525769B_=--