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

Janet P Gunn <jgunn6@csc.com> Fri, 28 June 2013 15:16 UTC

Return-Path: <jgunn6@csc.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 342D821F9B4A; Fri, 28 Jun 2013 08:16:21 -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 zJdjT8kX+geh; Fri, 28 Jun 2013 08:16:16 -0700 (PDT)
Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by ietfa.amsl.com (Postfix) with ESMTP id A789F21F9B3F; Fri, 28 Jun 2013 08:16:15 -0700 (PDT)
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-12.tower-171.messagelabs.com!1372432572!331545!1
X-Originating-IP: [20.137.2.88]
X-StarScan-Received:
X-StarScan-Version: 6.9.9; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32183 invoked from network); 28 Jun 2013 15:16:13 -0000
Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-12.tower-171.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Jun 2013 15:16:13 -0000
Received: from amer-gw09.amer.csc.com (cscmail.csc.com [20.6.39.245]) by amer-mta102.csc.com (8.13.8/8.13.8) with ESMTP id r5SFG48N029277; Fri, 28 Jun 2013 11:16:04 -0400
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3BD25A@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C3BD16D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3BD239@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C3BD25A@ESESSMB209.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
MIME-Version: 1.0
X-KeepSent: 97A56D05:62DA95E0-85257B98:005376F9; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012
From: Janet P Gunn <jgunn6@csc.com>
Message-ID: <OF97A56D05.62DA95E0-ON85257B98.005376F9-85257B98.0053E029@csc.com>
Date: Fri, 28 Jun 2013 11:16:08 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 06/28/2013 11:09:58 AM, Serialize complete at 06/28/2013 11:09:58 AM
Content-Type: multipart/alternative; boundary="=_alternative 0053DFEE85257B98_="
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: [sip-overload] NaN? RE: 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 15:16:21 -0000

Thanks Christer,

Syntax is definitely NOT my area of expertise, so I will let the authors 
follow up.

Eric and Philip,
What is supposed to happen when oc = "NaN"?  I do not see any reference to 
it in the rest of the document.  Is it even needed?

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>
To:     Christer Holmberg <christer.holmberg@ericsson.com>om>, Janet P 
Gunn/USA/CSC@CSC
Cc:     "sip-overload-bounces@ietf.org" <sip-overload-bounces@ietf.org>rg>, 
"draft-ietf-soc-overload-rate-control.all@tools.ietf.org" 
<draft-ietf-soc-overload-rate-control.all@tools.ietf.org>rg>, 
"sip-overload@ietf.org" <sip-overload@ietf.org>
Date:   06/28/2013 03:25 AM
Subject:        RE: [sip-overload] WGLC: 
draft-ietf-soc-overload-rate-control - Christer's comments



The following is obviously not needed in draft-ietf-soc-overload-control:
 
"EQUAL" is defined in RFC 3261.  "DIGIT" is defined in RFC 5234.
 
 
From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] 
On Behalf Of Christer Holmberg
Sent: 28. kesäkuuta 2013 9:27
To: Janet P Gunn
Cc: sip-overload-bounces@ietf.org; 
draft-ietf-soc-overload-rate-control.all@tools.ietf.org; 
sip-overload@ietf.org
Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - 
Christer's comments
 
Hi,
 
So, with the third alternative, Section 5 would look something like:
 
5.  Syntax
 
   This specification extends the existing definition of the Via header
   field parameters of [RFC3261] as follows:
 
        via-params =/ oc-nan
       oc-nan      = "NaN"
 
 
BTW, I think the syntax in draft-ietf-soc-overload-control should look 
like:
 
        via-params  =/ oc / oc-validity / oc-seq / oc-algo
 
       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
 
 
In both drafts, I would also suggest to rewrite the Syntax sections in the 
following way:
 
5.  Grammar
 
5.1.  General
 
   This section extends the ABNF definition of via-params from [RFC3261]
   by adding a new Via header field parameter, "oc-nan".  The ABNF defined
   in this specification is conformant to RFC 5234 [RFC5234].  "EQUAL"
   is defined in RFC 3261.  "DIGIT" is defined in RFC 5234.
 
5.2.  ABNF
 
   via-params =/ oc-nan
   oc-nan      = "NaN"
 
Regards,
 
Christer
 
 
 
 
From: Christer Holmberg 
Sent: 28. kesäkuuta 2013 8:40
To: Christer Holmberg; Janet P Gunn
Cc: sip-overload-bounces@ietf.org; 
draft-ietf-soc-overload-rate-control.all@tools.ietf.org; 
sip-overload@ietf.org
Subject: VS: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - 
Christer's comments
 
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; 
sip-overload@ietf.org; 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> 
To:        Janet P Gunn/USA/CSC@CSC 
Cc:        "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" <
draft-ietf-soc-overload-rate-control.all@tools.ietf.org>gt;, "
sip-overload@ietf.org" <sip-overload@ietf.org>rg>, "
sip-overload-bounces@ietf.org" <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 wrote on 06/27/2013 06:05:41 AM:

> From: Christer Holmberg <christer.holmberg@ericsson.com> 
> To: "sip-overload@ietf.org" <sip-overload@ietf.org> 
> Cc: "draft-ietf-soc-overload-rate-control.all@tools.ietf.org" 
> <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 
> 
> 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
> https://www.ietf.org/mailman/listinfo/sip-overload