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

From: Volker Hilt <[email-masked]>
Date: Wed, 1 Sep 2010 09:08:01 -0400

Janet,

thanks much for the detailed comments! I'll address them in the next 
version of the draft.

Thanks,

Volker

On 8/31/2010 11:24 AM, Janet P Gunn wrote:
>
> 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

---

From: <[email-masked]>
Date: Thu, 2 Sep 2010 10:18:50 +0200

I have one comment

The system model described in section 4 does not take into account the case where the receiving entity is a server farm. I believe it would be useful to add a description of this kind of architecture. In such a model, the server farm would comprise N servers, all of which including a SIP processor. One of the servers would also host the Control Function and the other ones would host a Monitor together with a copy of the application logic.  The server hosting the control function can be a front-end to the other servers or a logically independent server.  In the first case, the front-end server will typically incorporate load balancing logic so as to reduce the risk for the server farm and its individual servers to face overload conditions (See RFC5390 REQ23). 

Bruno 

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Salvatore Loreto
> Envoyé : mardi 31 août 2010 18:27
> À : [email-masked]
> Objet : Re: [sip-overload] WGLC: draft-ietf-soc-overload-design
> 
> 
>   [as chair]
> 
> we are more then halfway through this WGLC (it will end on 
> September 5th), and we have only seen one comment about it.
> Please take some time to review this draft and send your comments out.
> 
> cheers
> /Sal
> 
> 
> On 8/23/10 1:24 AM, Salvatore Loreto wrote:
> > [as chair]
> >
> > the draft has been update to address all the 
> concerns/suggestions that 
> > have been raised during the F2F meeting in Maastricht:
> >
> > http://tools.ietf.org/html/draft-ietf-soc-overload-design-01
> >
> >
> > the chairs believe the document has no remaining open 
> issues, and is 
> > ready for WG last call evaluation.
> >
> > Today we are starting a two-weeks working group last call.
> > This call end on September 5th.
> >
> > comments and especially full and deep reviews of the draft 
> are really 
> > appreciate.
> >
> >
> > cheers
> > Sal
> >
> 
> 
> --
> Salvatore Loreto
> www.sloreto.com
> 
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>

---

From: <[email-masked]>
Date: Tue, 28 Sep 2010 13:34:59 +0200

I did not receive any feeback about the comment I sent on September 2 about clause 4. Do you agree in principle?

BTW, I have another comment. I believe it would be useful to explicitly indicate in which of the models described in clause 9 the leaky bucket model falls. I assume it can be considered as a variant of the rate-based model but I think it would be worth stating this explicitly. T

Bruno

> De : CHATRAS Bruno RD-CORE-ISS 
> Envoyé : jeudi 2 septembre 2010 10:19
> À : 'Salvatore Loreto'; [email-masked]
> Objet : RE: [sip-overload] WGLC: draft-ietf-soc-overload-design
> 
> I have one comment
> 
> The system model described in section 4 does not take into 
> account the case where the receiving entity is a server farm. 
> I believe it would be useful to add a description of this 
> kind of architecture. In such a model, the server farm would 
> comprise N servers, all of which including a SIP processor. 
> One of the servers would also host the Control Function and 
> the other ones would host a Monitor together with a copy of 
> the application logic.  The server hosting the control 
> function can be a front-end to the other servers or a 
> logically independent server.  In the first case, the 
> front-end server will typically incorporate load balancing 
> logic so as to reduce the risk for the server farm and its 
> individual servers to face overload conditions (See RFC5390 REQ23). 
> 
> Bruno 
> 
> > Envoyé : mardi 31 août 2010 18:27 À : [email-masked] Objet : 
> > Re: [sip-overload] WGLC: draft-ietf-soc-overload-design
> > 
> > 
> >   [as chair]
> > 
> September 
> > 5th), and we have only seen one comment about it.

---

From: RahulSrivastava 71616 <[email-masked]>
Date: Tue, 28 Sep 2010 18:39:50 +0500

I have a similar doubt. 
For a server farm if there are more than one control servers. How does monitor servers tell control servers and in what ratio overload should be applied?

Regards,
Rahul

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************

----- Original Message -----
From: [email-masked]
Date: Tuesday, September 28, 2010 5:06 pm
Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-design
To: [email-masked], [email-masked]

> I did not receive any feeback about the comment I sent on 
> September 2 about clause 4. Do you agree in principle?
> 
> BTW, I have another comment. I believe it would be useful to 
> explicitly indicate in which of the models described in clause 9 
> the leaky bucket model falls. I assume it can be considered as a 
> variant of the rate-based model but I think it would be worth 
> stating this explicitly. T
> 
> Bruno
> 
> 
>