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

[<[e-mail]>]

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:[e-mail]] On Behalf Of
> Vijay K. Gurbani
> Sent: 04 June 2014 20:10
> To: [e-mail]
> Cc: [e-mail]
> Subject: [sip-overload] Review of draft-ietf-soc-overload-rate-control-
> 07.txt
> 
> 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 ..."
[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
>   approach./
[PhilW] 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...
> 
> - S3.3, first paragraph: s/string "rate"/token "rate"/
>   (in 2 places)
[PhilW] OK.
> 
> - 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  "...at a rate below their target (maximum) request rate..."?
> 
> - 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.
> 
>   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'
> 
> - 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.
[PhilW] Agreed.
> 
> - 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).
[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
>   subsumed by the discussion in [draft-ietf-soc-overload-control-15],
>   then simply say so).
[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.
> 
> 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} / [e-mail]
> Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
> 
> _______________________________________________
> sip-overload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload