From ecnoel@research.att.com Mon Apr 1 12:04:51 2013 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2E121F9318 for ; Mon, 1 Apr 2013 12:04:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2pZ6gwZ-isA for ; Mon, 1 Apr 2013 12:04:50 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id A3FD421F9316 for ; Mon, 1 Apr 2013 12:04:50 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 6DC9C1206B4; Mon, 1 Apr 2013 15:04:51 -0400 (EDT) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-green.research.att.com (Postfix) with ESMTP id 7F48AE376C; Mon, 1 Apr 2013 14:56:41 -0400 (EDT) Received: from njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%14]) with mapi; Mon, 1 Apr 2013 15:04:49 -0400 From: "NOEL, ERIC C (ERIC C)" To: "'Vijay K. Gurbani'" , "sip-overload@ietf.org" Date: Mon, 1 Apr 2013 15:04:49 -0400 Thread-Topic: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12 Thread-Index: Ac4pca05j/JnG5FWTpG3tLeWkDOh3QFmgPAQ Message-ID: <5EBD159DE88147488A3B1590E090018403531A0CE8B3@njfpsrvexg2.research.att.com> References: <51110A56.7030402@ericsson.com>, <51189F14.6050405@ericsson.com> <5EBD159DE88147488A3B1590E09001840353173DCBC2@njfpsrvexg2.research.att.com> <515074E1.4020909@bell-labs.com> In-Reply-To: <515074E1.4020909@bell-labs.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 Subject: Re: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 19:04:52 -0000 Vijay, Thanks for below. I am ok with your comments. Thanks,=20 Eric Noel=20 AT&T Labs, Inc.=20 Rethink Possible Network Design and Performance Analysis 200 South Laurel Avenue, D5-3D19 Middletown, NJ 07748 P: 732.420.4174 ecnoel@att.com -----Original Message----- From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of Vijay K. Gurbani Sent: Monday, March 25, 2013 12:02 PM To: sip-overload@ietf.org Subject: Re: [sip-overload] WG Last Call for draft-ietf-soc-overload-contro= l-12 On 02/17/2013 04:49 PM, NOEL, ERIC (ERIC C) wrote: > Salvatore, > > I read the document and have a few comments: Eric: Sorry for the delay; finishing up WGLC comments related to the draft.= Please see inline. > - Typos: > + Section 5.4 page 12, second paragraph "... is larger than the value > stored value, ...." --> "... is larger than the stored value, ..." > + Section 6.2 page 18, 7th paragraph, "20% for 1s." --> "20% for > 0.5s" or "oc-validity=3D500" --> "oc-validity=3D1000" Fixed. Thanks for a close read. > - Questions: > + Section 4.1 page 6, 4th paragraph, why using SHOULD and not MUST to > describe the client behavior upon receiving a response with the oc =20 > parameters filled in. This is in contrast with section 5.5 page 12, =20 > first paragraph, where a SIP client MUST honor overload control =20 > values it receives from downstream neighbors. Changed SHOULD to MUST. > + Section 4.4 page 8, 4th paragraph, following a sequence number > overflow, the server must reset the oc-seq parameter. Do we incur the =20 > risk of having the client ignore all server requests with the new =20 > oc-seq until oc-validity expires? Or does the client need to be able =20 > to identify when oc-seq was reset? That is a good question. I think that this an exceptional case and probabl= y best handled by alerting the implementer of this instead of trying to be = prescriptive using rfc-2119 language. To that extent, I can add some explanatory text as the last paragraph of S4= .4 as follows: Due to an overflow, client implementations should be prepared to receive an "oc-seq" parameter whose value is less than the previous value. Client implementations can handle this by continuing to perform overload control until the "oc-validity" related to the previous value of "oc-seq" parameter expires. If someone has a better way to handle this case, please let me know. > + Section 7, should there be any mention of draft-soc-overload-rate-contr= ol? draft-soc-overload-rate-control is mentioned already as a companion overloa= d control scheme throughout the document. Thus I see no specific reason to= mention it in S7. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload From vkg@bell-labs.com Mon Apr 8 12:29:56 2013 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C4F21F8ACE for ; Mon, 8 Apr 2013 12:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.2 X-Spam-Level: X-Spam-Status: No, score=-110.2 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFBnEkOK0UkG for ; Mon, 8 Apr 2013 12:29:55 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFAE21F905A for ; Mon, 8 Apr 2013 12:29:55 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r38JTsgx029783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 8 Apr 2013 14:29:54 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r38JTsau014789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 8 Apr 2013 14:29:54 -0500 Received: from shoonya.ih.lucent.com (vkg.lra.lucent.com [135.244.19.127]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r38JTrUI005164 for ; Mon, 8 Apr 2013 14:29:53 -0500 (CDT) Message-ID: <51631B69.1010901@bell-labs.com> Date: Mon, 08 Apr 2013 14:32:57 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: "sip-overload@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [sip-overload] WG attention to 2 questions on draft-ietf-soc-overload-control-12 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 19:29:56 -0000 Folks: As part of the 2nd WGLC review done by Janet, there are 2 questions that should benefit from some discussion. These need to be closed so we can move the draft ahead to IESG. Please see [1] for these questions. Some feedback would be appreciated. [1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00925.html Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From internet-drafts@ietf.org Mon Apr 8 12:44:57 2013 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6428D21F9075; Mon, 8 Apr 2013 12:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voeUFexBnAe4; Mon, 8 Apr 2013 12:44:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7ADF21F88C6; Mon, 8 Apr 2013 12:44:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p3 Message-ID: <20130408194454.11826.40652.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2013 12:44:54 -0700 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-overload-rate-control-04.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 19:44:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Overload Control Working Group of the= IETF. Title : Session Initiation Protocol (SIP) Rate Control Author(s) : Eric Noel Philip M Williams Filename : draft-ietf-soc-overload-rate-control-04.txt Pages : 15 Date : 2013-04-08 Abstract: The prevalent use of Session Initiation Protocol (SIP) [RFC3261] in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. Already [draft-ietf-soc-overload-control-12] proposes a loss-based solution to remedy known vulnerabilities of the [RFC3261] SIP 503 (service unavailable) overload control mechanism. This document proposes a rate-based control solution to complement the loss-based control defined in [draft-ietf-soc-overload-control-12]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-soc-overload-rate-control There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-soc-overload-rate-control-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-overload-rate-control-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rlb@ipv.sx Wed Apr 17 10:53:38 2013 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4583421F8DE4 for ; Wed, 17 Apr 2013 10:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.064 X-Spam-Level: X-Spam-Status: No, score=-1.064 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzCfas9rxGB0 for ; Wed, 17 Apr 2013 10:53:37 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 45B5F21F8E46 for ; Wed, 17 Apr 2013 10:53:36 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id ta14so1683122obb.28 for ; Wed, 17 Apr 2013 10:53:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=pg1Jj7yf23VIbEG74qPXuTM4PygdnNp6lDSkNpW2i0o=; b=HrnTh44rpTM9wQpOkZ85bgWiuq/NMHG5AwSGPPvSsejdo58DAQ5guM43/qsK2LnZNk 3UD0XIec065PNtHSNPRiLbmjLz1UVbdOyPCVy5hboSKRtpc4scWb3f6c20YPPWps+ptt NsDWkblb/inL9VVZSUNB4fuSYFxmV/nz6qYGkZ5uZGLad0Hd+z9ylku7VHyQhMltD6n8 4TylSQZEvlRMCtQDt148oR3MMZFGPExUg0T1mIJCzRIuUoywqQGwjlMDxbo7TSXDFViJ X0xdBOAjA4P7x4JROHYZKnbpIEx2rJ8zfXh097M61OHaLNRhUQRXZ4iv3H0/Q6XhPw39 ZeXQ== MIME-Version: 1.0 X-Received: by 10.60.103.165 with SMTP id fx5mr3360088oeb.4.1366221210616; Wed, 17 Apr 2013 10:53:30 -0700 (PDT) Received: by 10.60.25.196 with HTTP; Wed, 17 Apr 2013 10:53:30 -0700 (PDT) X-Originating-IP: [192.1.255.184] Date: Wed, 17 Apr 2013 13:53:30 -0400 Message-ID: From: Richard Barnes To: sip-overload@ietf.org, draft-ietf-soc-load-control-event-package@tools.ietf.org Content-Type: multipart/alternative; boundary=089e0112c404f18ec404da922956 X-Gm-Message-State: ALoCoQn13MBwedsvkhRgS4/loLeppbQw+na95lPeY9XNNMl2KkiVPCrWgJ0VJXK/KtrpYP37yLLi Subject: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 17:53:38 -0000 --089e0112c404f18ec404da922956 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document, and have a few questions before IETF LC: Major: In a few places, for example Section 5.3., the document suggests that this event package could be used to communicate load filtering policies between domains. This seems like a bad idea for a few reasons. First, policies can be based on "P-Asserted-Identity", which is itself limited to use within a trust domain / Spec(T). It doesn't make sense to have policies based on these identifiers outside of the domain in which they are used. Second, inter-domain policies can create subtle and dangerous security risks. For example, according to the current specification, Domain A could tell Domain B to drop all calls between Domain B and Domain C. It's not clear how you would prevent these sorts of attacks, especially where "tel:" URIs are involved. I think both of these issues go away if this event package is limited in a similar way to P-Asserted-Identity, i.e., limited to use within a trust domain. Section 6.3., "SUBSCRIBE Bodies" doesn't actually say anything about what goes in the body of a SUBSCRIBE message. On the one hand, it implies that there could be a body (since the last sentence considers a request without a body as a special case), but it doesn't say what goes in the body if there is one. Please either (1) define what may go in the body, (2) explicitly say that this document does not specify what goes in SUBSCRIBE bodies, or (3) require that the body be empty. (Also, the first paragraph of this section seems out of place here, since it also has nothing to do with the body.) In Section 6.5., the last sentence is wrong. The presence of an Accept header indicates that the response body should be one of the indicated types. The indicated behavior would only be acceptable if the Accept header included "multipart/mixed". Suggest deleting the last sentence. (Also, it would be clearer to change "the request body will contain" to "the request body MUST contain".) In Section 7.3.1, you need to specify how a "tel:" URI is matched against a domain value starting with "+". Your examples seem to indicate simple string prefix matching, but I doubt that's what you actually want, since non-digit characters can break things. For example, "+1212" should match " +1-212-555-1212". Please specify a matching algorithm here. In Section 7.3.2, please change "Non-initial requests ... are not subjected" to "Non-initial requests ... MUST NOT be subjected". Section 7.4. doesn't adequately define the actions to be taken. Each of the action elements (, , ) need to define a concrete action that the proxy should take. RFC 4745 allows rules to combine when multiple rules match a given call. This document needs to define combination rules for the actions defined here. What's the reason for having both the "drop" action and the "reject" action? It seems like the "drop" action is almost always harmful. With unreliable transport, it causes retransmits, and even with reliable transport, it causes the client to wait unnecessarily until the connection times out. In any case, the "simple drop" action is underspecified. For example, does the server simply ignore the SIP message, or does it close the transport connection? Minor: In Section 7.3, "we re-define" -- the document doesn't re-define any of the elements in RFC 4745 (that's good; redefinition is bad). Instead, you should say you define new identity elements. In Section 7.3.1, please break up paragraph starting "To include the two forms..." for greater readability. Suggested break points: Before "Note that the tradeoff...", and before "It should be noted..." In Section 7.3.3, it would be helpful to break up the paragraph starting "The following are two example...". Break before "Usecase I" and "Usecase II". Also, s/Usecase/Use case/g Thanks, --Richard --089e0112c404f18ec404da922956 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have reviewed this document, and h= ave a few questions before IETF LC:

Major:

In a few places, for exampl= e Section 5.3., the document suggests that this event package could be used= to communicate load filtering policies between domains. =A0This seems like= a bad idea for a few reasons. =A0First, policies can be based on "P-A= sserted-Identity", which is itself limited to use within a trust domai= n / Spec(T). =A0It doesn't make sense to have policies based on these i= dentifiers outside of the domain in which they are used. =A0Second, inter-d= omain policies can create subtle and dangerous security risks. =A0For examp= le, according to the current specification, Domain A could tell Domain B to= drop all calls between Domain B and Domain C. =A0It's not clear how yo= u would prevent these sorts of attacks, especially where "tel:" U= RIs are involved. =A0I think both of these issues go away if this event pac= kage is limited in a similar way to P-Asserted-Identity, i.e., limited to u= se within a trust domain.

Section 6.3., "SUBSCRIBE Bodies" doesn't actually say anythin= g about what goes in the body of a SUBSCRIBE message. =A0On the one hand, i= t implies that there could be a body (since the last sentence considers a r= equest without a body as a special case), but it doesn't say what goes = in the body if there is one. =A0Please either (1) define what may go in the= body, (2) explicitly say that this document does not specify what goes in = SUBSCRIBE bodies, or (3) require that the body be empty. =A0 (Also, the fir= st paragraph of this section seems out of place here, since it also has not= hing to do with the body.)

In Section 6.5., the last sentence is wrong. =A0The presence of an Accept h= eader indicates that the response body should be one of the indicated types= . =A0The indicated behavior would only be acceptable if the Accept header i= ncluded "multipart/mixed". =A0Suggest deleting the last sentence.= =A0(Also,=A0=A0it would be clearer to change "the request body will c= ontain" to "the request body MUST contain".)

In Section 7.3.1, you need to specify how a "tel:" URI is matched= against a domain value starting with "+". =A0Your examples seem = to indicate simple string prefix matching, but I doubt that's what you = actually want, since non-digit characters can break things. =A0For example,= "+1212" should match "+1-212= -555-1212". =A0Please specify a matching algorithm here.

In Section 7.3.2, please change "Non-initial requests ... are not subj= ected" to "Non-initial requests ... MUST NOT be subjected".<= /div>

Section 7.4. doesn't ad= equately define the actions to be taken. =A0Each of the action elements (&l= t;rate>, <window>, <percent>) need to define a concrete acti= on that the proxy should take.=A0

RFC 4745 allows rules to combine when multiple rules match a given call. = =A0This document needs to define combination rules for the actions defined = here. =A0

What's the reason for h= aving both the "drop" action and the "reject" action? = =A0It seems like the "drop" action is almost always harmful. =A0W= ith unreliable transport, it causes retransmits, and even with reliable tra= nsport, it causes the client to wait unnecessarily until the connection tim= es out. =A0In any case, the "simple drop" action is underspecifie= d. =A0For example, does the server simply ignore the SIP message, or does i= t close the transport connection?


Minor:

In Section 7.3, "we re= -define" -- the document doesn't re-define any of the elements in = RFC 4745 (that's good; redefinition is bad). =A0Instead, you should say= you define new identity elements.

In Section 7.3.1, please break up paragraph starting "To include the t= wo forms..." for greater readability. =A0Suggested break points: Befor= e "Note that the tradeoff...", and before "It should be note= d..."

In Section 7.3.3, it would be helpful to break up the paragraph starting &q= uot;The following are two example...". =A0Break before "Usecase I= " and "Usecase II". =A0Also, s/Usecase/Use case/g


Thanks,
--Richard
--089e0112c404f18ec404da922956-- From hammondjohnson@hushmail.com Sat Apr 27 17:27:54 2013 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617D121F9965 for ; Sat, 27 Apr 2013 17:27:54 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1UJh+mcVWfn for ; Sat, 27 Apr 2013 17:27:53 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id 53BC521F9959 for ; Sat, 27 Apr 2013 17:27:53 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id 01B6A30583 for ; Sat, 27 Apr 2013 17:48:48 +0000 (UTC) X-hush-relay-time: 214 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:48:48 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id BE55BE6736; Sat, 27 Apr 2013 17:48:48 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:48:48 -0400 To: sip-overload@ietf.org From: hammondjohnson@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427174848.BE55BE6736@smtp.hushmail.com> Subject: [sip-overload] Biggest Fake Conference in Computer Science X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 00:27:54 -0000 We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From volker.hilt@bell-labs.com Mon Apr 29 06:54:15 2013 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D22821F9A3F for ; Mon, 29 Apr 2013 06:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdNYaCyJFYsz for ; Mon, 29 Apr 2013 06:54:15 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 07E3121F976A for ; Mon, 29 Apr 2013 06:54:11 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r3TDsBp2024407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 29 Apr 2013 08:54:11 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r3TDsA4I023011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 29 Apr 2013 09:54:10 -0400 Received: from [149.204.61.163] (135.5.27.18) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 29 Apr 2013 09:54:10 -0400 Message-ID: <517E7B7F.7030609@bell-labs.com> Date: Mon, 29 Apr 2013 15:54:07 +0200 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: References: <51631B69.1010901@bell-labs.com> In-Reply-To: <51631B69.1010901@bell-labs.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.5.27.18] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [sip-overload] WG attention to 2 questions on draft-ietf-soc-overload-control-12 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 13:54:15 -0000 Vijay, All, here are my comments on the two questions: - oc-algo parameter: this parameter specifies the semantics of the oc value and defines how that is to be interpreted by the receiver. It does not define the algorithm used to compute the oc-algo parameter. The important thing is that the receiver knows what it need to do with the received oc parameter. This is reflected in the following statement in the draft. Might be worth while to further clarify in the next rev of the draft. The "oc-algo" parameter contains a token or a list of tokens corresponding to the class of overload control algorithms supported by the client. - I think the current writeup regarding the processing cycles dedicated to upstream neighbors is fine. Thanks, Volker (as individual) On 08.04.2013 21:32, Vijay K. Gurbani wrote: > Folks: As part of the 2nd WGLC review done by Janet, there are 2 > questions that should benefit from some discussion. These need > to be closed so we can move the draft ahead to IESG. > > Please see [1] for these questions. Some feedback would be > appreciated. > > [1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00925.html > > Thanks, > > - vijay