Re: [sip-overload] Sec 5 and 6 Re: WG Last Call for draft-ietf-soc-overload-control-12

"Vijay K. Gurbani" <vkg@bell-labs.com> Fri, 22 March 2013 15:58 UTC

Message-ID: <514C8055.9060607@bell-labs.com>
Date: Fri, 22 Mar 2013 11:01:25 -0500
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
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: Janet P Gunn <jgunn6@csc.com>
References: <51110A56.7030402@ericsson.com> <51189F14.6050405@ericsson.com> <OF1EFD032C.5418DF57-ON85257B27.000B56FE-85257B27.000B9603@csc.com>
In-Reply-To: <OF1EFD032C.5418DF57-ON85257B27.000B56FE-85257B27.000B9603@csc.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: Volker Hilt <volker.hilt@alcatel-lucent.com>, "sip-overload@ietf.org" <sip-overload@ietf.org>
Subject: Re: [sip-overload] Sec 5 and 6 Re: WG Last Call for draft-ietf-soc-overload-control-12
Precedence: list

Janet: Please see inline.

There are two open questions resulting from Janet's feedback below.
Some WG input will be needed to close them.  Please see inline.

On 03/06/2013 08:06 PM, Janet P Gunn wrote:
> Sec 5.10.2 Rejecting Requests at an overloaded server.
>
> I agree with the concept
> “It would be fair to devote the same amount
>     of processing at the overloaded server to the combination of
>     rejection and processing from a non-participating client as the
>     overloaded server would devote to processing requests from a
>     participating client.”
>
> But how is the server to know how much it “would devote to processing
> requests from a  participating client.” Especially under the loss scheme.
>
> It seems to me that it would make more sense to estimate
> R = ratio of (processing required to reject a request) to (processing
> required to process a request)
>
> Then for the loss algorithm, if the server would have set oc=x, it
> should reject (1+R)x % of the requests from the non participating client.
>
> For the rate algorithm,   if the server would have set oc=x, it should
> reject anything over x/ (1+R) requests per second from the non
> participating client.

My question to the WG would be whether we want to go into this level
of detail or simply leave it to the implementation to know how much
it spends in processing requests from clients?

> Sec 6.2
> “some algorithm called "A".”
>
> Is there any way to be sure that, when the client says “A” and the
> server says “A”, they mean the same thing?

We register the Via header field parameter (S11), but we do not
establish a registry for the tokens that go into the "oc-algo"
parameter.

Another question to the WG: do we need to establish a registry for
the tokens that need to go into the "oc-algo" parameter?

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] Introduction - "This document defi… Janet P Gunn
[sip-overload] Sec 5.8 Re: WG Last Call for draft… Janet P Gunn
[sip-overload] Sec 5 and 6 Re: WG Last Call for d… Janet P Gunn
Re: [sip-overload] WG Last Call for draft-ietf-so… Vijay K. Gurbani
[sip-overload] WG Last Call for draft-ietf-soc-ov… Salvatore Loreto
Re: [sip-overload] WG Last Call for draft-ietf-so… Salvatore Loreto
Re: [sip-overload] WG Last Call for draft-ietf-so… bruno.chatras
Re: [sip-overload] WG Last Call for draft-ietf-so… Atle Monrad
Re: [sip-overload] WG Last Call for draft-ietf-so… NOEL, ERIC (ERIC C)
Re: [sip-overload] Introduction - "This document … Vijay K. Gurbani
Re: [sip-overload] Sec 5.8 Re: WG Last Call for d… Vijay K. Gurbani
Re: [sip-overload] Sec 5 and 6 Re: WG Last Call f… Vijay K. Gurbani
Re: [sip-overload] WG Last Call for draft-ietf-so… bruno.chatras
Re: [sip-overload] WG Last Call for draft-ietf-so… Vijay K. Gurbani
Re: [sip-overload] WG Last Call for draft-ietf-so… Vijay K. Gurbani
Re: [sip-overload] WG Last Call for draft-ietf-so… NOEL, ERIC C (ERIC C)