Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - PLEASE COMMENT!

"NOEL, ERIC C (ERIC C)" <ecnoel@research.att.com> Mon, 24 June 2013 22:09 UTC

Return-Path: <ecnoel@research.att.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 2A84711E8193; Mon, 24 Jun 2013 15:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 hIla10HN3wm0; Mon, 24 Jun 2013 15:09:37 -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 8EB7E11E818C; Mon, 24 Jun 2013 15:09:37 -0700 (PDT)
Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 83088120631; Mon, 24 Jun 2013 18:09:36 -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 A128FE0210; Mon, 24 Jun 2013 18:08:23 -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, 24 Jun 2013 18:09:35 -0400
From: "NOEL, ERIC C (ERIC C)" <ecnoel@research.att.com>
To: 'Janet P Gunn' <jgunn6@csc.com>, Salvatore Loreto <salvatore.loreto@ericsson.com>
Date: Mon, 24 Jun 2013 18:09:35 -0400
Thread-Topic: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - PLEASE COMMENT!
Thread-Index: Ac5oPNSekMjntMG7Syac8vIqkZXn/AIr6+qw
Message-ID: <5EBD159DE88147488A3B1590E09001840353BDA4CA98@njfpsrvexg2.research.att.com>
References: <519F3A0B.7090507@bell-labs.com> <51B87951.6070100@ericsson.com> <OF50DE3F41.3480F042-ON85257B89.004ADC52-85257B89.004BE964@csc.com>
In-Reply-To: <OF50DE3F41.3480F042-ON85257B89.004ADC52-85257B89.004BE964@csc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_5EBD159DE88147488A3B1590E09001840353BDA4CA98njfpsrvexg2_"
MIME-Version: 1.0
Cc: "sip-overload-bounces@ietf.org" <sip-overload-bounces@ietf.org>, "sip-overload@ietf.org" <sip-overload@ietf.org>, Volker Hilt <volker.hilt@bell-labs.com>
Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - PLEASE COMMENT!
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: Mon, 24 Jun 2013 22:09:43 -0000

Janet,

Thank you for your insightful comments.

Please see my responses:

[Janet Gunn] Needs to be made clearer that the "default algorithms" are simply "existence" examples, and that other rate based algorithms can be used.
[Eric Noel] I believe you proposed a resolution to this comment in your 6/20 detailed comments email. Note that I approved your proposed resolution there.

[Janet Gunn]  Need to be clearer about what the constraints (how strictly they limit traffic) are on other algorithms (and for the default algorithms too - if you make TAU too big, you are not really limiting to a specific rate)
[Eric Noel] Because there are several variations for rate-based overload control algorithms, it is not clear how to set such a constraint across all such variations. However, with the provided reasonable values for the proposed rate-based overload control algorithm (please see below), a constraint is implicitly provided (for the proposed algorithm).

[Janet Gunn]  Need to make it clearer that only "T" (the target rate) is transmitted in the "oc" value.  The other parameters (TAU, TAU0, TAU1, TAU2) are not part of the message protocol.
[Eric Noel] Yes, only the target rate is transmitted in the "oc" value. Section 3.5.1 specifies that "T is computed as the inverse of the rate specified in the oc value, namely T = 1 / oc-value." While in Section 4 usage example, it is stated that the overloaded element P2 "...sends the following SIP message indicating P1 should send SIP requests at a rate no greater than or equal to 150 SIP requests per seconds." Where the message oc value is set to oc=150.
=> In light of the above, do you still want to have some text added to specifically state that parameters TAU, TAU0, TAU1, TAU2 are not exchanged through the overload control scheme.
[Janet Gunn] Are you expecting that there will be some external negotiation between the client and the server on appropriate values for these "tolerance" parameters? Or are you expecting that the client will pick values for these parameters on its own, without involving the server in the decision?
[Eric Noel] Tolerance parameters defined in the default rate-based overload control algorithm are specific to that default algorithm and not expected to be negotiated between clients and servers. The expectation is that if the clients where to use the proposed default rate-based overload control algorithm, clients will be pre-provisioned with values for the tolerance parameters.

[Janet Gunn] Since they are default algorithms, it would make sense (and make it easier to follow) to give default, or recommended, values for TAU, TAU0, TAU1, TAU2.
[Eric Noel] Comment addressed in your 6/20 email.

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Network Design and Performance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174
ecnoel@att.com<mailto:jsmith@att.com>

From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of Janet P Gunn
Sent: Thursday, June 13, 2013 9:49 AM
To: Salvatore Loreto
Cc: sip-overload-bounces@ietf.org; sip-overload@ietf.org; Volker Hilt
Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - PLEASE COMMENT!

(Coming out from under analysis of the Boston Bombing overload, the Oklahoma Tornado overload, etc.)

I am working on some more detailed comments, but here are a couple of higher level things

Needs to be made clearer that the "default algorithms" are simply "existence" examples, and that other rate based algorithms can be used.

Need to be clearer about what the constraints (how strictly they limit traffic) are on other algorithms (and for the default algorithms too - if you make TAU too big , you are not really limiting to a specific rate)

Need to make it clearer that only "T" (the target rate) is transmitted in the "oc" value.  The other parameters (TAU, TAU0, TAU1, TAU2) are not part of the message protocol.
Are you expecting that there will be some external negotiation between the client and the server on appropriate values for these "tolerance" parameters?
 Or are you expecting that the client will pick values for these parameters on its own, without involving the server in the decision?

Since they are default algorithms, it would make sense (and make it easier to follow) to give default, or recommended,  values for TAU, TAU0, TAU1, TAU2.

More later, and hoping these thunderstorms don't lead to more overloads!

Janet
.

sip-overload-bounces@ietf.org<mailto:sip-overload-bounces@ietf.org> wrote on 06/12/2013 09:36:17 AM:

> From: Salvatore Loreto <salvatore.loreto@ericsson.com<mailto:salvatore.loreto@ericsson.com>>
> To: Volker Hilt <volker.hilt@bell-labs.com<mailto:volker.hilt@bell-labs.com>>
> Cc: "sip-overload@ietf.org<mailto:sip-overload@ietf.org>" <sip-overload@ietf.org<mailto:sip-overload@ietf.org>>
> Date: 06/12/2013 09:36 AM
> Subject: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control -
> PLEASE COMMENT!
> Sent by: sip-overload-bounces@ietf.org<mailto:sip-overload-bounces@ietf.org>
>
> Dear SoC WG participants
>
> we are trying to finalize all the SIP Overload efforts before the next
> IETF meeting in Berlin.
>
> The Overload-Rate-Control is the last wg-item we have, and in order to
> progress it,
> we need people reading and reviewing and a clear evidence that people
> have done it.
> Comments and especially full and deep reviews of the draft are really
> appreciate, but also simple feedback
> like "I have read the draft and I think is ready for IESG" would be enough.
>
> We haven't received any comments from the first call so we are extending
> the WGLC till Fri Jun 21th.
>
> This is our last draft, let's make a final push to get this done.
>
> Thanks
> Salvatore
>
> On 5/24/13 12:59 PM, Volker Hilt wrote:
> > Folks,
> >
> > with draft-ietf-soc-overload-control-13 getting close to finalization,
> > we are ready to start the WGLC for our last remaining draft:
> >
> > http://www.ietf.org/id/draft-ietf-soc-overload-rate-control-04.txt
> >
> > The WGLC will end on Fri Jun 7.
> >
> > Please review the draft and send your comments to the mailing list. It
> > is very important that the WG reviews this draft. YOUR comments are
> > important - even if it is just to say you agree!
> >
> > This is our last draft, let's make a final push to get this done.
> >
> > Thanks,
> >
> > Salvatore and Volker
> > SOC WG co-chairs
> >
>
>
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org<mailto:sip-overload@ietf.org>
> https://www.ietf.org/mailman/listinfo/sip-overload