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

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 04 Jun 2014 14:10:27 -0500

Eric, Philip: I was asked by the chairs to review draft-ietf-soc-
overload-rate-control-07.txt.

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 ..."

- S1, fourth paragraph, last sentence: s/loss approach./loss-based
  approach./

- 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?

- S3.3, first paragraph: s/string "rate"/token "rate"/
  (in 2 places)

- 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.

- 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.

  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: ...

- S4: In the SIP messages of the example, there appear to be spurious
  new lines between header elements.  Plus, when a continuation appears
  on a new line in SIP, the first token of the new line has a LWS.  Thus,
  the Via line in the INVITE is best written as:

    Via: SIP/2.0/TLS p1.example.net;
      branch=z9hG4bK2d4790.1;received=192.0.2.111;
      oc;oc-algo="loss,rate"

  and similarly for the response.

- S6: I suspect that this draft can refer to the Security Considerations
  section of [draft-ietf-soc-overload-control-15] by reference instead of
  by value (so to speak).

  Of more interest would be a discussion of threats specific to the rate-
  based algorithm (if there aren't any, or if all such threats are
  subsumed by the discussion in [draft-ietf-soc-overload-control-15],
  then simply say so).

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} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: <[email-masked]>
Date: Fri, 13 Jun 2014 15:08:54 +0100

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.

Regards,

Phil

> -----Original Message-----
> From: sip-overload [mailto:[email-masked]] On Behalf Of
> Vijay K. Gurbani
> Sent: 04 June 2014 20:10
> To: [email-masked]
> Cc: [email-masked]
> Subject: [sip-overload] Review of draft-ietf-soc-overload-rate-control-
> 07.txt
> 
> Here are my comments, in document order.  Generally, the draft is well
> written; some of the comments below may be helpful.
> 
[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.
E.g. one possible interpretation might be that SIP Rate Control is a 'specialisation' (or 'extension'?) of SIP Overload Control. By this I mean that (logical implication)
	conformance to SIP Rate Control => conformance to SIP Overload Control
However one of the features of SIP Overload Control is that the loss-based method must be supported by both clients and servers (the latter follows because if a client only specifies "loss" then the server has no other choice). Therefore since both client and server must support the rate-based method for SIP Rate Control, the 'specialisation' interpretation would imply that for SIP Rate Control clients and servers would support both methods. However there isn't any statement in draft-ietf-soc-overload-rate-control-07 that clients must support the loss-based method as well. On the other hand an 'alternative' interpretation could be that neither the client nor the server are required to support the loss-based method (but may do). This would be similar to SIP Overload Control where, in terms of default/mandatory method, the roles of 'loss' and 'rate' are transposed (in fact one can map 5.1-Determining support for overload control from draft-ietf-soc-overload-control-15 in this way). I expect  that this is the intention. In this case it would be worth stating this explicitly - in addition to the mandatory references to the rate-based method - just for clarity. A natural place to do this would be in the last paragraph of 3.3.
So which is really intended - 'alternative' or 'specialisation'? I have argued in the past that clients should support both and it is the server that should dictate the method, so I would be happy with 'specialisation', but I appreciate that others would not be given the outcome of the earlier debate about SIP Overload Control, which gave rise to the creation of this SIP Rate Control draft. In any case if we go for 'alternative' then the two sets of requirements are compatible, i.e. if it is required to conform to SIP Overload Control AND SIP Rate Control then it follows that clients and servers should support both algorithms. This gives flexibility for practical implementation [the only issue I have with this is that it is a stronger requirement than may be required in many situations - where we want all clients to support both methods, but servers can support only one of them].
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.

> - S1, fourth paragraph, last sentence: s/loss approach./loss-based
[PhilW] Agreed.
>   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...
> - S3.3, first paragraph: s/string "rate"/token "rate"/
[PhilW] OK.
>   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  "...at a rate below their target (maximum) request rate..."?
>   control-15] as much as an artifact of how the loss-based algorithm
[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.
>   similar categories.  Thus it is best to specify the opening sentence
>   of S3.5.2 as follows:
> 
[PhilW] I suggest that this should read 'two or more categories', or 'at least two categories'
>   on a new line in SIP, the first token of the new line has a LWS.
>   Thus, the Via line in the INVITE is best written as:
> 
[PhilW] Agreed.
>   section of [draft-ietf-soc-overload-control-15] by reference instead
>   of by value (so to speak).
[PhilW] Yes - reference would be better in order to ensure everything is kept up-to-date.
> 
>   Of more interest would be a discussion of threats specific to the
>   rate-based algorithm (if there aren't any, or if all such threats are
[PhilW] I think it is covered by draft-ietf-soc-overload-control-15. In fact in that discussion it does point out that there is a difference in the ability of the overloaded server to police arriving traffic rates from specific clients, i.e. since it does not know the arrival rate at the client before restriction, for proportional rejection (loss-based) the server does not know whether the client is conforming, whereas for the rate-based method the server will know it isn't if the rate it receives from a client exceeds the control rate significantly between updates.
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 25 Jun 2014 10:28:44 -0500

On 06/13/2014 09:08 AM, [email-masked] wrote:
> 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.

> [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.

> [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.
> 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.

> [PhilW] Yes it is a little ambiguous but I think this is because the grammar
> is incorrect - would this do  "...at a rate below their target (maximum)
> request rate..."?

Yes.

> [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 ...

> or 'at least two categories'

... works for me.

Thanks,

- vijay

---

From: "NOEL, ERIC C" <[email-masked]>
Date: Wed, 25 Jun 2014 17:23:41 +0000

Vijay, Phil, thanks for the comments and suggestions.

I added resolutions in-line below.

Thanks,

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
[email-masked]

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

[...]

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

EN> Agreed

EN> Adopting Phil's edit

> is incorrect - would this do  "...at a rate below their target (maximum)

Yes.
EN> Agreed

Sure ...

... works for me.

EN>Suggest:
"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: ..."

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 25 Jun 2014 12:30:50 -0500

[...]
> control algorithm.  The rate-based control algorithm guarantees an upper bound ..."

Eric: Works for me.

The rest of the conversation was mostly in agreement, so I will not
quote it here.

Thanks,

- vijay