IETF Logo Mail Archive

Re: [sip-overload] SIP overload control draft

Padma Valluri <pvalluri@csc.com> Wed, 16 June 2010 15:53 UTC

Return-Path: <pvalluri@csc.com>
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 6A46228C147 for <sip-overload@core3.amsl.com>; Wed, 16 Jun 2010 08:53:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.061
X-Spam-Level:
X-Spam-Status: No, score=-5.061 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wch99Gt2jDkF for <sip-overload@core3.amsl.com>; Wed, 16 Jun 2010 08:53:58 -0700 (PDT)
Received: from mail94.messagelabs.com (mail94.messagelabs.com [216.82.241.179]) by core3.amsl.com (Postfix) with ESMTP id 16F763A693F for <sip-overload@ietf.org>; Wed, 16 Jun 2010 08:53:57 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: pvalluri@csc.com
X-Msg-Ref: server-4.tower-94.messagelabs.com!1276703639!62385917!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [20.137.2.88]
Received: (qmail 17460 invoked from network); 16 Jun 2010 15:53:59 -0000
Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-4.tower-94.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Jun 2010 15:53:59 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id o5GFrwOk006749 for <sip-overload@ietf.org>; Wed, 16 Jun 2010 11:53:58 -0400
Importance: Normal
X-Priority: 3 (Normal)
Sensitivity:
In-Reply-To: <4C17EB15.2040003@bell-labs.com>
References: <4C167D6D.7080809@bell-labs.com> <OFB461FA7A.8C1F0324-ON85257742.007973EF-85257742.007973F7@csc.com>, <4C16B18E.8080209@bell-labs.com> <OF15FF93CF.3AF0DB1E-ON85257743.00500206-85257743.0050020D@csc.com>, <4C17DE47.7080508@bell-labs.com> <OF828785E4.A6EE2635-ON85257743.00714B42-85257743.00714B4B@csc.com>, <4C17EB15.2040003@bell-labs.com>
MIME-Version: 1.0
From: Padma Valluri <pvalluri@csc.com>
To: "Vijay K. Gurbani" <vkg@bell-labs.com>
Message-ID: <OFD66D2D69.35DEBF65-ON85257744.0057558B-85257744.00575592@csc.com>
Date: Wed, 16 Jun 2010 11:53:55 -0400
X-Mailer: Lotus Domino Web Server Release 8.5.1FP1 January 05, 2010
X-MIMETrack: Serialize by Notes Server on AMER-ML20/SRV/CSC(Release 8.5.1FP1|January 05, 2010) at 06/16/2010 11:53:55, Serialize complete at 06/16/2010 11:53:55, Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.1FP1 HF293|April 16, 2010) at 06/16/2010 11:54:33 AM
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Volker Hilt <volker.hilt@alcatel-lucent.com>, sip-overload@ietf.org, Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [sip-overload] SIP overload control draft
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Overload <sip-overload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-overload>
List-Post: <mailto:sip-overload@ietf.org>
List-Help: <mailto:sip-overload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Jun 2010 15:53:59 -0000

Vijay,

Thanks for your response. Comments in-line.

Padma.

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


-----"Vijay K. Gurbani" <vkg@bell-labs.com> wrote: -----

To: Padma Valluri/USA/CSC@CSC
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Date: 06/15/2010 05:05PM
cc: sip-overload@ietf.org, Volker Hilt <volker.hilt@alcatel-lucent.com>, Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [sip-overload] SIP overload control draft

On 06/15/2010 03:37 PM, Padma Valluri wrote:
>     Sure, but by the time the request hits the server again, it may not be
>     overloaded. If it still is overloaded and refuses to respond, it will
>     continue to be avoided.
>
>     [PV] Sure, but aren't we looking for a better mechanism than the
>     existing ones and be more deterministic?

Let's be sure that we're on the same page here.  The above
discussion is predicated on the text in Section 3.6 that
discusses what to do when the downstream server does not
respond *at all*.  If it does, then yes, we are attempting to
design a more deterministic mechanism.  In other words,
we may be in vehement agreement but still debating a moot
point.

To recap, if the downstream server responds and it supports
overload control, the new mechanism we are designing kicks in.
If it does not respond at all for the lifetime of a transaction,
then the upstream server avoids it (and most production
servers already do so.)

[PV] Understood. When there is no response from an overloaded server, it will help to have a notify mechanism in place to signal the upstream nodes that its ready for requests when the congestion is abated, not just wait for timeout. This would also reduce retries, retransmissions and rerouting (at application level) in a more persistent congestion scenario.

>     [PV] Not sure if you need to specify how to implement the traffic
>     reduction towards a node in the draft. If the server wants to reduce
>     the load by 25%, it might just drop every 4th request going to the
>     congested neighbor. The oc value might change before you reach the
>     right sample to be close to the average.

I think providing some guidance is not a bad idea.  An implementer
can always substitute a better algorithm if he or she wants to.

Thanks,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/" target="blank" rel="nofollow">http://ect.bell-labs.com/who/vkg/


v2.23.0 | Report a Bug | By Email