Re: [MEDIACTRL] [sip-overload] WGLC: draft-ietf-soc-overload-design

[Janet P Gunn <[e-mail]>]

Comments on draft-ietf-soc-overload-design-01

Intro, third paragraph says:
“For example, a PSTN gateway that runs
   out of trunk lines but still has plenty of capacity to process SIP
   messages should reject incoming INVITEs using a 488 (Not Acceptable
   Here) response [RFC4412].”

While it is true that 4412 DOES say to use 488 in this case, we have found 
that, in the real world, this can lead to incorrect mapping back to ISUP. 
In at least some contexts, “503 with a Reason header field Q.850 cause 
value of 34 (no circuit available)” may be used instead of 488.  (I 
believe this is covered in a PTSC document.)  So I suggest 

“For example, a PSTN gateway that runs
   out of trunk lines but still has plenty of capacity to process SIP
   messages should reject incoming INVITEs using a response such as 488 
(Not Acceptable
   Here), as described in RFC4412.”

After this paragraph, I would add a new paragraph saying something like:

“There are other failure cases in which a SIP server also serves non-SIP 
traffic (e.g., RTP packets, database queries and updates, event handling) 
which can lead to server overload.  These other loads may, or may not, be 
correlated with the SIP message volume. The server is unable to process 
all SIP requests due to resource constraints, but simply reducing the flow 
of SIP messages may not sufficiently reduce the load to avoid congestion 
collapse.  In this context, it is to be expected that the server has some 
other method of overload control addressing these other sources of load. 
However, the specifics of the overload control for other traffic types, 
and the coordination of the different overload controls, are out of scope 
for this document.” 

This should address Partha’s, and others’ concerns.

Fourth paragraph.

In addition to the other problems with 503 and Retry-After, 503 is used 
for other situations (with or without Retry-After), not just SIP Server 
overload.  A SIP Overload Control process based on 503 would have to 
specify exactly which cause values trigger the Overload Control.

Section 2

Even when SIP messages are not dropped, significant delay can cause 
time-outs which lead to retransmission.  I would change the second 
sentence to 
“When SIP is running over the UDP protocol, it will retransmit messages 
that were dropped or excessively delayed by a SIP server due to overload 
and thereby increase the offered load for the already overloaded server.”

At the end of section 2 you say
  “Another challenge for SIP overload control is that the rate of the
   true traffic source usually cannot be controlled.  Overload is often
   caused by a large number of UAs each of which creates only a single
   message.  These UAs cannot be rate controlled as they only send one
   message.  However, the sum of their traffic can overload a SIP
   server.”

In fact, the various wireless technologies DO have method for controlling 
the load “caused by a large number of UAs each of which creates only a 
single message.”  Some of these are of the form “pick a random number and 
see if it exceeds the threshold you have been given”.

Examples include Access Class Barring, and Access Persistence Mechanism. 
It would be possible to do something similar at the SIP level, though it 
would probably be redundant.

My suggested rewording would be:

“Another challenge for SIP overload control is controlling the rate of the 
true traffic source.  Overload is often caused by a large number of UAs 
each of which creates only a single message.  However, the sum of their 
traffic can overload a SIP server. The overload mechanisms suitable for 
controlling a SIP server (e.g., rate control) may not be effective for 
individual UAs.  In some cases, there are other non-SIP mechanisms for 
limiting the load from the UAs.  These may operate independently from, or 
in conjunction with, the SIP overload mechanisms described here.  In 
either case, they are out of scope for this document.”

Section 4

Your model is built on the premise of a “sending entity” and a “receiving 
entity”.  In the real world, not only is Server A sending SIP messages to 
Server B, but Server B is also sending SIP messages to Server A.

I don’t think you should clutter up your model by trying to address both 
directions at once, but you should state somewhere in the text that you 
have made that simplification/abstraction for ease of comprehension, and 
that any mechanism must work in the context of “SIP messages going both 
ways”.

My suggestion would be to add another sentence after 
“The model in Figure 1 shows a scenario with one sending and one
   receiving entity.  In a more realistic scenario a receiving entity
   will receive traffic from multiple sending entities and vice versa
   (see Section 6).”

My suggestion would be:
“In addition, in a more realistic scenario, SIP messages will be going 
both directions, from B to A as well as A to B.  However, the overload 
control mechanisms in each direction can be considered independently.”

Then, in section 5.1, change 
“Each control loop between two servers is
   completely independent of the control loop between other servers
   further up- or downstream.” 
To
“Each control loop between two servers is
   completely independent of the control loop between other servers
   further up- or downstream, and of the control loop between the two 
servers in the other direction.” 

Section 8, 
second paragraph
After “An
   overload control mechanism should ensure that the delay encountered
   by a SIP message is not increased significantly during periods of
   overload.”
Add
“Significantly increased delay can lead to time-outs, and retransmission 
of SIP messages, making the overload worse.”

“Reactiveness” doesn’t seem the right word to me.  “Responsiveness” sounds 
better to me.

End of section 8
Another important metric is the (cpu) load used by the overload “monitor” 
and “actuator”.

End of section 9
Suggest changing 
“Explicit overload control
   mechanisms can be differentiated based on the type of information
   conveyed in the overload control feedback and whether the control
   function is in the receiving or sending entity (receiver- vs. sender-
   based overload control).” 
To
“Explicit overload control
   mechanisms can be differentiated based on the type of information
   conveyed in the overload control feedback and whether the control
   function is in the receiving or sending entity (receiver- vs. sender-
   based overload control), or both.” 

In 9.2, I think 
“A loss percentage enables a SIP server to ask an upstream neighbor to
   reduce the number of requests it would normally forward to this
   server by a percentage X. For example, a SIP server can ask an
   upstream neighbor to reduce the number of requests this neighbor
   would normally send by 10%.  The upstream neighbor then redirects or
   rejects X percent of the traffic that is destined for this server.”
Should be
“A loss percentage enables a SIP server to ask an upstream neighbor to
   reduce the number of requests it would normally forward to this
   server by a X%. For example, a SIP server can ask an
   upstream neighbor to reduce the number of requests this neighbor
   would normally send by 10%.  The upstream neighbor then redirects or
   rejects 10% of the traffic that is destined for this server.”

End of 9.2
WRT:
“Thus, percentage throttling requires an adjustment of the throttling
   percentage in response to the traffic received and may not always be
   able to prevent a server from encountering brief periods of overload
   in extreme cases.”
This is not unique to percentage throttling.  It is possible in rate based 
and window based methods as well.  In all cases, it is heavily dependent 
on the frequency of updates by the control mechanism.  But that needs to 
be balanced against the load generated by the control mechanism.  I am not 
sure whether it makes sense to say something in each method, or put it up 
front as a general comment.

Sec 9.4
Here again, remember that there are many other things that can generate 
503, with or without Retry-After.

Sec 11
Last paragraph add:
“Conversely, the semantics of any proposed approach should permit a 
variety of different algorithms.”




Nits/wordsmithing
Note at end of section 6, change “different than” to “different from”.

Section 12 first para
Change 
“Overload control can require a SIP server to prioritize requests and
   select requests that need to be rejected or redirected.”
To
“Overload control can require a SIP server to prioritize requests and
   select requests to be rejected or redirected.”

Sec 12
Third para
Change 
“Responses should not be targeted when a SIP server is trying to
   reduce load for a number of reasons.”
To
“For a number of reasons, SIP responses should not be dropped in order to
   reduce SIP processing load”


Janet