IETF Logo Mail Archive

Re: [sip-overload] The frequency of re-negotiating overload control schemes

Shida Schubert <shida@ntt-at.com> Wed, 07 September 2011 13:49 UTC

Return-Path: <shida@ntt-at.com>
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 33E5821F8B7A for <sip-overload@ietfa.amsl.com>; Wed, 7 Sep 2011 06:49:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Level:
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 v7UceYhr8Fzy for <sip-overload@ietfa.amsl.com>; Wed, 7 Sep 2011 06:49:26 -0700 (PDT)
Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id B783121F8B70 for <sip-overload@ietf.org>; Wed, 7 Sep 2011 06:49:25 -0700 (PDT)
Received: from [122.135.156.233] (port=60383 helo=[192.168.1.139]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <shida@ntt-at.com>) id 1R1IWv-0003Y2-VO; Wed, 07 Sep 2011 08:51:08 -0500
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=us-ascii
From: Shida Schubert <shida@ntt-at.com>
In-Reply-To: <4E676532.4060408@alcatel-lucent.com>
Date: Wed, 7 Sep 2011 22:51:03 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <8CE63924-C744-4A00-9F7A-FB7491B4C7B0@ntt-at.com>
References: <4E613160.5010701@bell-labs.com> <A7854CEA-AC39-434E-82E6-C9E608B7741B@ntt-at.com> <4E661C01.3010803@bell-labs.com> <BECE4232-9F57-4FDF-9D3F-2D8D29484C75@ntt-at.com> <4E66DB5F.1090205@bell-labs.com> <4E676532.4060408@alcatel-lucent.com>
To: Volker Hilt <volker.hilt@alcatel-lucent.com>
X-Mailer: Apple Mail (2.1244.3)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator465.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ntt-at.com
X-BWhitelist: no
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: fl1-122-135-156-233.tky.mesh.ad.jp ([192.168.1.139]) [122.135.156.233]:60383
X-Source-Auth: shida@agnada.com
X-Email-Count: 1
X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t
Cc: sip-overload@ietf.org
Subject: Re: [sip-overload] The frequency of re-negotiating overload control schemes
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload <sip-overload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 07 Sep 2011 13:49:27 -0000

My comments inline..

On Sep 7, 2011, at 9:36 PM, Volker Hilt wrote:

> On 9/6/2011 10:47 PM, Vijay K. Gurbani wrote:
>> On 09/06/2011 07:23 PM, Shida Schubert wrote:
>>> Okay, fair enough.
>>> 
>>> I guess we should probably mandate the inclusion of "oc-algo" in that
>>> case. It is currently stated on 4.1 as "MAY" add an "oc-algo"..
>>> 
>>> One can assume that not having "oc-algo" indicates that the client
>>> only supports or wants to use the default "loss" based algorithm but
>>> if that is the case we should probably have a statement saying that
>>> too.
>>> 
>>> I prefer mandating the inclusion of "oc-algo" so it is always clear
>>> what the client/server means/wants.
>> 
> I agree.
> 
> Following up on the previous discussion of having the client include only the current algorithm. I think the selection of the algorithm is essentially a server issue. Once the server knows which algorithms the client supports it can pick one. I'm not sure what the value is of having the client include only the currently selected algorithm and trigger a renegotiation once in a while.
> 
> I think the client should always include all supported algorithms. The server gets to choose since it needs to shoulder the burden of generating the feedback for each client.

 I agre with your opinion that it is really the server side that really 
cares what algorithm it uses, so I think this is better. 

> 
> In the spirit of keeping things simple, I don't think expressing preferences adds much value. The client should send a flat list the sever can choose from.

 If client doesn't benefit from certain algorithm being selected, I agree. 

 Regards
  Shida

> 
> The draft should, of course, have a discussion about chosing the algorithm in the server (i.e., not changing it often, etc)
> 
> Thanks,
> 
> Volker [as individual]
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload

v2.8.7 | Report a Bug | By Email