Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 28 June 2013 05:40 UTC

Return-Path: <christer.holmberg@ericsson.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 D615821F9E5C; Thu, 27 Jun 2013 22:40:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.423
X-Spam-Level:
X-Spam-Status: No, score=-4.423 tagged_above=-999 required=5 tests=[AWL=1.825, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 AJckRaoR+qvJ; Thu, 27 Jun 2013 22:40:09 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D880321F9EF9; Thu, 27 Jun 2013 22:40:07 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fec6d000002a90-eb-51cd21b193f1
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D5.94.10896.1B12DC15; Fri, 28 Jun 2013 07:40:01 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Fri, 28 Jun 2013 07:40:00 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Janet P Gunn <jgunn6@csc.com>
Thread-Topic: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments
Thread-Index: Ac5zweEAF4KSgJ2oQr+eAJpjbv955Q==
Date: Fri, 28 Jun 2013 05:40:01 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3BD16D@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.146]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3BD16DESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+Jvre5GxbOBBm82aFhc2HGM1eLcwy+s Fu0Xt7Ja7H+a4MDicfF6lMeSJT+ZPL5c/swWwBzFZZOSmpNZllqkb5fAlfHr2Ea2ghN7mSu2 vHRuYPyzkbmLkZNDQsBE4sHJWywQtpjEhXvr2boYuTiEBA4zSrQs2ATlLAJy5t0F6uDgYBOw kOj+pw1iigiES0xZ5QpSwizwnlHi1ooZjCCDhAXiJBo2XAUbKiIQL/Fy93xGCFtPYuuNdlYQ m0VAVWLiii4mEJtXwFeib1kbO4jNCHTE91NrwOLMAuISHw5ehzpUQGLJnvNQtqjEy8f/WCFs JYkfGy6xQNTnS2y79pURYqagxMmZT1gmMArPQjJqFpKyWUjKZgG9wyygKbF+lz5EiaLElO6H 7BC2hkTrnLnsyOILGNlXMbLnJmbmpJcbbmIERs/BLb91dzCeOidyiFGag0VJnHeT3plAIYH0 xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyinA1SU2b+0dV63XiH20w0tK1m9e2elvPp0Xtt74Z5 8xv21U0qO9dwXPV7iovkrVyPZaFP+jhmfsqbxjytUOK4bp+I3PJUzl3CdrnhQutiFrzb2ho1 99GWRPWLLIkC5XbfbzpdEvn5KPPw16dlT/6fnvsn1qDP9N68+//szq99nnRPh6N3YZUSS3FG oqEWc1FxIgDX5HpsbAIAAA==
Cc: "sip-overload-bounces@ietf.org" <sip-overload-bounces@ietf.org>, "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" <draft-ietf-soc-overload-rate-control.all@tools.ietf.org>, "sip-overload@ietf.org" <sip-overload@ietf.org>
Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments
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: Fri, 28 Jun 2013 05:40:15 -0000

Hi,

A third alternative (probably the easiest one, at least from a syntax perspective) would be to simply define a new “oc-nan” Via header field parameter.

oc-nan          = "nan"

…or something like that.

It would not require any changes to draft-ietf-soc-overload-control .

(Then, in the procedure sections you need to describe how/whether the oc and oc-nan parameters can be used at the same time etc, but that is not a syntax question.)

Regards,

Christer


Lähettäjä: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] Puolesta Christer Holmberg
Lähetetty: 27. kesäkuuta 2013 22:42
Vastaanottaja: Janet P Gunn
Kopio: sip-overload-bounces@ietf.org; draft-ietf-soc-overload-rate-control.all@tools.ietf.org; sip-overload@ietf.org
Aihe: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments

Hi,

When taking a closer look, I actually think there is something technically wrong with the syntax in Section 5 of draft-ietf-soc-overload-rate-control.

draft-ietf-soc-overload-control  defines the oc parameter as:

oc          = "oc" [EQUAL oc-num]


Now, it seems like draft-ietf-soc-overload-rate-control actually re-defines the same parameter. In addition, it’s done in a backward compatible manner, e.g. because the parameter can now contain a non-numeric value (see the bullet list below what can go wrong):

oc          = "oc" EQUAL oc-value


The following can happen:


1.       If an entity that supports draft-ietf-soc-overload-control  receives “oc=NaN” it will reject it, as it expects a numeric value.

2.       If an entity that supports draft-ietf-soc-overload-rate-control receives “oc” it will reject it, as it expects an oc-value. But, in draft-ietf-soc-overload-control  the usage of oc-value is optional.


One way to fix this could be to define oc-value as a separate Via header field parameter (similar to oc-validity, oc-seq etc), instead of a value of the oc parameter. But, then you would have oc-num

Another way is to change the syntax in draft-ietf-soc-overload-control , in order to allow what you want to do in draft-ietf-soc-overload-rate-control.

Regards,

Christer




Lähettäjä: Janet P Gunn [mailto:jgunn6@csc.com]
Lähetetty: 27. kesäkuuta 2013 22:04
Vastaanottaja: Christer Holmberg
Kopio: draft-ietf-soc-overload-rate-control.all@tools.ietf.org<mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>; sip-overload@ietf.org<mailto:sip-overload@ietf.org>; sip-overload-bounces@ietf.org<mailto:sip-overload-bounces@ietf.org>
Aihe: Re: VS: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - Christer's comments

Christer

 draft-ietf-soc-overload-control  says
" 8.  Syntax

   This specification extends the existing definition of the Via header
   field parameters of [RFC3261] as follows:

       via-params  =  via-ttl / via-maddr
                      / via-received / via-branch
                      / oc / oc-validity
                      / oc-seq / oc-algo / via-extension


       oc          = "oc" [EQUAL oc-num]
       oc-num      = 1*DIGIT
       oc-validity = "oc-validity" [EQUAL delta-ms]
       oc-seq      = "oc-seq" EQUAL 1*12DIGIT "." 1*5DIGIT
       oc-algo     = "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list)
                     DQUOTE
       algo-list   = "loss" / *(other-algo)
       other-algo  = %x41-5A / %x61-7A / %x30-39
       delta-ms    = 1*DIGIT"
and
"11.  IANA Considerations

   This specification defines four new Via header parameters as detailed
   below in the "Header Field Parameter and Parameter Values" sub-
   registry as per the registry created by [RFC3968].  The required
   information is:

       Header Field  Parameter Name  Predefined Values  Reference
       __________________________________________________________
       Via           oc                 Yes             RFCXXXX
       Via           oc-validity        Yes             RFCXXXX
       Via           oc-seq             Yes             RFCXXXX
       Via           oc-algo            Yes             RFCXXXX

       RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC
       number of this specification.]"

The text of draft-ietf-soc-overload-control refers to both "loss" and "rate"  as values for  oc-algo.

The text of draft-ietf-soc-overload-control  section 5.3 refers to the use of oc for either rate or loss

"As an example, a value of "oc=10" when the loss-based algorithm is
   used implies that 10% of the total number of SIP requests (dialog
   forming as well as in-dialogue) are subject to reduction at the
   client.  Analogously, a value of "oc=10" when the rate-based
   algorithm [I-D.ietf-soc-overload-rate-control] is used indicates that
   the client should send SIP requests at a rate of 10 SIP requests or
   fewer per second."

What are you suggesting would go in the "IANA Considerations" section of  draft-ietf-soc-overload-rate-control ?  Does it just need a reference to the IANA Considerations in draft-ietf-soc-overload-control?

Janet






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.



From:        Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
To:        Janet P Gunn/USA/CSC@CSC
Cc:        "draft-ietf-soc-overload-rate-control.all@tools.ietf.org<mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>" <draft-ietf-soc-overload-rate-control.all@tools.ietf.org<mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>>, "sip-overload@ietf.org<mailto:sip-overload@ietf.org>" <sip-overload@ietf.org<mailto:sip-overload@ietf.org>>, "sip-overload-bounces@ietf.org<mailto:sip-overload-bounces@ietf.org>" <sip-overload-bounces@ietf.org<mailto:sip-overload-bounces@ietf.org>>
Date:        06/27/2013 12:54 PM
Subject:        VS: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control -        Christer's comments
________________________________



Hi,

>The IANA considerations section of  draft-ietf-soc-overload-control registers the new Via header field parameters.
>
>Is it needed here as well?

The draft (Section 5) does extend the oc parameter, doesn’t it? I would assume that needs to go to IANA.

Regards,

Christer


sip-overload-bounces@ietf.org<mailto:sip-overload-bounces@ietf.org> wrote on 06/27/2013 06:05:41 AM:

> From: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
> To: "sip-overload@ietf.org<mailto:sip-overload@ietf.org>" <sip-overload@ietf.org<mailto:sip-overload@ietf.org>>
> Cc: "draft-ietf-soc-overload-rate-control.all@tools.ietf.org<mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>"
> <draft-ietf-soc-overload-rate-control.all@tools.ietf.org<mailto:draft-ietf-soc-overload-rate-control.all@tools.ietf.org>>
> Date: 06/27/2013 06:05 AM
> Subject: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control -
> Christer's comments
> Sent by: sip-overload-bounces@ietf.org<mailto:sip-overload-bounces@ietf.org>
>
> Hi,
>
> I have read draft-ietf-soc-overload-rate-control-04.txt as part of the WGLC.
>
...
> Q7: In Section 7 you say that there are no IANA considerations. But,
> don’t you need to request IANA to register the new Via header field
> parameters?
>
> Regards,
>
> Christer
>
>
>
>
>  _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org<mailto:sip-overload@ietf.org>
> https://www.ietf.org/mailman/listinfo/sip-overload