Re: [sip-overload] Review of draft-ietf-soc-overload-rate-control-07.txt

"NOEL, ERIC C" <> Wed, 25 June 2014 17:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 71EC21B2D84 for <>; Wed, 25 Jun 2014 10:24:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KSROGASvL4kt for <>; Wed, 25 Jun 2014 10:24:30 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6851E1B2D87 for <>; Wed, 25 Jun 2014 10:24:30 -0700 (PDT)
Received: from unknown [] (EHLO by with ESMTP id (envelope-from <>); Wed, 25 Jun 2014 17:24:30 +0000 (UTC)
X-MXL-Hash: 53ab05ce46311062-35d5022ee5326a3893d3be03c875c50464bedd9e
Received: from unknown [] (EHLO by over TLS secured channel with ESMTP id (envelope-from <>); Wed, 25 Jun 2014 17:24:13 +0000 (UTC)
X-MXL-Hash: 53ab05bd2470f7ac-7aa9bd0a05174e52972a59bea7a9b617383da799
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id s5PHO9bE003151; Wed, 25 Jun 2014 13:24:09 -0400
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s5PHO01I003024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jun 2014 13:24:01 -0400
Received: from ( []) by (RSA Interceptor); Wed, 25 Jun 2014 17:23:43 GMT
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Wed, 25 Jun 2014 13:23:43 -0400
From: "NOEL, ERIC C" <>
To: "Vijay K. Gurbani" <>, "" <>
Thread-Topic: [sip-overload] Review of draft-ietf-soc-overload-rate-control-07.txt
Thread-Index: AQHPgChj2wFDhq/GbEusmX+lpS30fZtvZMEAgBLySQD//9ImAA==
Date: Wed, 25 Jun 2014 17:23:41 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=OJ6QK1mB c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a]
X-AnalysisOut: [=IpeXJiYOrl0A:10 a=ofMgfj31e3cA:10 a=T371OWOketIA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=e9qsufxtAAAA:8 a=N54-gffFAAAA:8 ]
X-AnalysisOut: [a=gxZvrgisAAAA:8 a=C3I3ZF1iAAAA:8 a=_b_RclnsAAAA:20 a=9tQV]
X-AnalysisOut: [VCdFAAAA:20 a=HtYIgt-ClAZp3w7tKh0A:9 a=CjuIK1q_8ugA:10 a=Q]
X-AnalysisOut: [YbaF5LxmtMA:10 a=V4Yg_9LqF70A:10 a=jd7AbVFD4xwA:10 a=Hz7Ir]
X-AnalysisOut: [DYlS0cA:10 a=lZB815dzVvQA:10 a=W1qU_X6G3J8A:10 a=sK9FX98U6]
X-AnalysisOut: [w4A:10 a=nAPXUAfsBmEA:10 a=3FZX-ydVlcEA:10]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
Cc: "" <>, "" <>
Subject: Re: [sip-overload] Review of draft-ietf-soc-overload-rate-control-07.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Overload <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Jun 2014 17:24:34 -0000

Vijay, Phil, thanks for the comments and suggestions.

I added resolutions in-line below.


Eric Noel 
AT&T Labs, Inc. 
Rethink Possible

Optimization, Reliability and Customer Analytics
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174

-----Original Message-----
From: sip-overload [] On Behalf Of Vijay K. Gurbani
Sent: Wednesday, June 25, 2014 11:29 AM
Subject: Re: [sip-overload] Review of draft-ietf-soc-overload-rate-control-07.txt

On 06/13/2014 09:08 AM, wrote:
> Vijay,
> Thanks for your comments. My responses embedded below. I think
> Eric may respond next week.
> I can suggest some more specific suggested wording/revisions for
> my first somewhat lengthy reply, but I was hoping to get some
> other views about this  first.

Phil: Please see inline.  Issues that we agreed on are removed
from inlining below.

>> Here are my comments, in document order.  Generally, the draft is well
>> written; some of the comments below may be helpful.
>> - S1, fourth paragraph: The rate-control draft is not as much an
>>    extension to draft-ietf-soc-overload-control as much as it is
>>    a specification for an alternative overload control mechanism.
>>    As such, probably best to state that "This document proposes an
>>    alternative, rate-based overload control algorithm within the
>>    framework defined in [draft-ietf-soc-overload-control-15].  The
>>    rate-based control algorithm guarantees an upper bound ..."
> [PhilW] Please excuse me for a bit of semantic ramble: I suspect that
> some readers may get confused about how the two specs relate to each
> other - I know that I have been. I suggest that we should be more
> explicit about how they differ, because the intention is that they
> are essentially the same (using the same framework) but with a few
> key differences.
> To summarise, if the intention is an 'alternative' set of
> requirements, which is the same as SIP Overload Control, but where
> the default(mandatory) restriction algorithm is rate-based rather
> than loss-based (the latter being optional), then it would be
> helpful to state this explicitly.

The intention of the WG was that the rate-control draft contain a
overload based scheme that is not loss-based, the tautological
impact of the first half of this sentence notwithstanding.

The only default and m-t-i algorithm that the WG decided to go with
is loss-based.  However, the framework makes provisions to plug in
other algorithms.  And rate-based is one of them.

Insofar as requirements are concerned, I don't see that the rate-control
draft imposes an "alternative set of requirements" as stated above.
The requirements of overload are satisfied by the overload-control
draft, so I am at a loss to see why rate-control is deriving new
requirements when we consider it as an alternative overload scheme.

Supporting rate-control implies supporting overload-control.  An
implementation cannot say it supports overload control if it only
implements the rate-control scheme and nothing else.

EN> Suggest:
"In accordance with the framework defined in [draft-ietf-soc-overload-control-15],  
 this document proposes an alternate overload control, the rate-based overload 
control algorithm.  The rate-based control algorithm guarantees an upper bound ..."

>> - S1, fourth paragraph, last sentence: s/loss approach./loss-based
>>    approach./
> [PhilW] Agreed.

EN> Agreed

>> - S3.2: I am not sure what is the implication of the last paragraph.
>>    I suspect a value in the oc parameter that triggers overload control
>>    at the client informs the client of "overload state".  Why this
>>    overload state occurred (i.e., what resources are being exhausted by
>>    the server) is rather immaterial at the client, no?
> [PhilW] I'm not sure of the intended meaning here either - furthermore it
> is not the desired rate, but the desired maximum rate. I would be happy
> to move it to the start of the section (or delete it altogether), i.e.
> 3.2. Via header field parameters for overload control
> The use of the via header oc parameter(s) inform clients of the
> desired maximum rate. They are defined in
> [draft-ietf-soc-overload-control-14] and summarized below...

Either of these actions is fine.  I have no preference.

EN> Adopting Phil's edit

>> - S3.4, sixth paragraph: "... at a rate below its target SIP request
>>    rate..."  Here, "its" refers to client? or server?  I think it is the
>>    client, but some clarification would be good.
> [PhilW] Yes it is a little ambiguous but I think this is because the grammar
> is incorrect - would this do  " a rate below their target (maximum)
> request rate..."?

EN> Agreed

>> - S3.5.2: the fact that the client maintains two categories of requests,
>>    one subject to reduction and the other not, is an artifact of the
>>    loss-based algorithm in [draft-ietf-soc-overload-control-15].  Thus, I
>>    don't think that this is a requirement of [draft-ietf-soc-overload-
>>    control-15] as much as an artifact of how the loss-based algorithm
>>    works.
> [PhilW] I don't think that there is such a dependence upon the loss-based
> algorithm in 5.10.1 of draft-ietf-soc-overload-control-15, and my
> interpretation is that this section doesn't necessarily imply just
> two levels of priority (say normal and 'priority'). In fact since several
> types of 'high priority' requests are discussed in 5.10.1, one can
> envisage that they may be classed as different priority levels, although
> I am not necessarily implying that is necessarily a good approach from
> a performance perspective.

Sure ...

>>    That said, almost any client will automatically gravitate towards two
>>    similar categories.  Thus it is best to specify the opening sentence
>>    of S3.5.2 as follows:
>>       As with the loss-based algorithm of [draft-ietf-soc-overload-
>>       control-15], a client implementing the rate-based algorithm also
>>       prioritizes messages into two categories of requests: ...
> [PhilW] I suggest that this should read 'two or more categories',
> or 'at least two categories'

... works for me.

"As with the loss-based algorithm of [draft-ietf-soc-overload-control-15], 
a client implementing the rate-based algorithm also  prioritizes messages
 into two or more categories of requests: ..."


- vijay
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{,} /
Web:  | Calendar:

sip-overload mailing list