Subject: RE: [Sipping] Overload solutions comments

From: "Terpstra, Rich" <[email-masked]>
Date: Fri, 28 Jul 2006 08:48:42 -0600

Thanks. I was really just pointing out a real problem to consider to see
if whatever approach is selected will help solve it. As a network
operator, if I can stop a call that can't complete as early in the
process as possible, it saves my resources for other calls that I can
complete. I am hoping that the overload header will help with this
problem.

Rich Terpstra
 
Level 3 Communications
Softswitch Architecture
1025 Eldorado Blvd, Broomfield, CO, 80021
 Office: (720) 888-2994

-----Original Message-----
From: Volker Hilt [mailto:[email-masked]] 
Sent: Thursday, July 27, 2006 10:32 PM
To: Terpstra, Rich
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Sipping] Overload solutions comments

Hi Rich,

thanks much for the comments! More inline.

Terpstra, Rich wrote:
> I don't remember if the working group came to a consensus regarding 
> hop-by-hop versus end-to-end load values for the two different 
> solutions. When reviewing the hop-by-hop approach, I thought of a 
> third possible approach, which is to return the value of the most 
> loaded element to the UAC. This solves a couple of problems that the 
> hop-by-hop doesn't address and keeps the message smaller than the 
> end-to-end approach. It also solves the problem of intermediary 
> proxies not supporting the header, as long as they pass it upstream 
> unchanged. The busiest element approach allows each hop to compare the

> value in the header to its own load value. If the proxy's load is 
> higher, it places itself into the header. Otherwise, it leaves the 
> header as-is and passes it upstream. The UA can decide what to do with

> the information as well as the hop before the congested element.
> 
The main problem with the busiest element approach is that it can cause
a proxy to falsely report overload even though it is not overloaded at
all and could still forward messages to other non-overloaded proxies. 
Here is an example:
                      95
                     +---+
           10   95/--| C |
+---+ 95 +---+ /    +---+
| A |----| B |       10
+---+    +---+ \    +---+
                10\--| D |
                     +---+

In this example, C is overloaded and reports a load 95 to B. D is fine
and reports a load of 10. In the busiest element approach, B would
report a load of 95 to A (since 95 is higher than its own value of 10). 
Thus, B would effectively report overload and ask A to stop forwarding
traffic to it even though it is doing fine and proxy D can still be
reached through B. Essentially, one overloaded leaf node in a
distribution tree would shut down the traffic to all other nodes in the
tree by reporting overload that is passed upstream.

Another approach is one that works entirely on an end-to-end basis
(i.e., only endpoints report load). However, this also has its problems.

Assume that in the above example B is running at a load of 95 whereas C
and D are running at 10. If only the load of C and D is reported
upstream, A would not become aware of the overload in B and would not
throttle traffic.

The only way to make this work seems to be a path-based overload
control, in which each proxy along the path to a certain target reports
its load upstream. The problem with this is that it is complex and very
hard to do right. This approach would require large load reports (one
load sample for each proxy on the way) and it seems very hard for a
receiver of such a multi-sample report to determine the correct action
based to this feedback information. E.g., by how much should it throttle
traffic, which destinations are affected, how are multiple paths to the
same destination handled, ...

> The problem I have that the hop-by-hop approach doesn't solve is that 
> as an operator, I see that congestion usually occurs at the UAS and 
> not at the intermediary proxies.

A UAS can use overload control the same way as a proxy. I don't see a
UAS specific problem here.

> A Network normally has multiple routes to reach a UAS through diverse 
> proxies, so the proxies themselves rarely congest. The UAS, however, 
> can become a bottleneck that with the hop-by-hop approach could cause 
> a domino affect to the intermediary proxies.

The upstream neighbor of an overloaded UAS does not get clogged by the
messages it can't deliver. When it receives an overload indication and
does not have an alternative route for the target it will start to
reject messages instead of forwarding them (e.g. using a reasonable
retry after value). Only when the traffic increases further to a point
where even the proxy can't reject all messages any more, it will send an
overload indication to its upstream neighbor and ask the neighbor to
start throttling load.

> The end-to-end approach allowed the UAC to know that the UAS was 
> congested, so UAC could choose to release some sessions destined for 
> the UAS, which would avoid congesting the intermediary proxies. I 
> believe reporting the most congested element will also allow the UAC 
> to avoid choosing some or all routes based on which element is
congested.
> 
> Consider the following example to illustrate how it appears that 
> hop-by-hop doesn't help alleviate congestion, but in fact acerbates
it:
>                                     
>                                     
>                                     
> +-----+    +-------+    +--------+   +--------+            
> | (A) |--->|  (B)  |--->|   (C)  |-->|  (D)   |\              
> +-----+    +-------+    +--------+   +--------+ \            
>  PSTN          |                                 \+------+
+-----+
>                |                                  |  (F) |----->| (G)
|
>                |                                 /+------+
+-----+
>                |        +--------+   +--------+ /
>                +------->|  (H)   |-->|  (E)   |/
>                         +--------+   +--------+
> 
> 
> SIP 
> ------------------------------------------------------------------>
> 
> (A) - Phone		(E) - Proxy
> (B) - UA		(F) - B2BUA
> (C) - Proxy		(G) - Phone
> (D) - Proxy       (H) - Proxy
> 
> A phone (A) in the PSTN calls a phone (G) on a SIP network. The PSTN 
> routes the call to a carrier who owns the number for phone (G) via a 
> UA (B). The carrier determines that there are two diverse routes 
> through the carrier's network for reaching phone (G). Carrier sends 
> call from UA
> (B) to proxy (C).  Proxy (C) sends call to proxy (D). Proxy (D) sends 
> call to the Feature Server (F) where phone (G) is registered. Call 
> arrives at B2BUA (F), but B2BUA (F) is overloaded. B2BUA (F) will 
> complete the call to phone (G), but will report its load to proxy (D).
> Proxy (D) will pass its load back to proxy (C). Proxy (C) passes its 
> load back to UA (B). Let's say that B2BUA (F) Load = 80, proxy (D) 
> Load = 20, and proxy (C) Load = 30.
> 
> A new call comes into the same UA (B) destined for the same B2BUA (F).
> UA
> (B) sends call to proxy (H). Proxy (H) sends to proxy (E). Proxy (E) 
> does not know about the load on B2BUA (F), so proxy (E) sends call to 
> B2BUA (F). B2BUA (F) completes call to phone (G). B2BUA (F) reports 
> its load now as
> 85 to proxy (E). Proxy (E) reports its load of 20 back to proxy (H).
> Proxy (H) sends back its load of 30 to UA (B).
> 
> A third call comes into UA (B) destined for same B2BUA (F). UA (B) 
> sends call to proxy (C). Proxy (C) sends call to proxy (D). Proxy (D) 
> sees B2BUA
> (F) is loaded at 80, so it chooses not to offer the call to B2BUA (F).
> Proxy (D) releases the call with 503 to proxy (C). Proxy (C) sends 
> back
> 503 to UA (B). UA (B) has a second route to B2BUA (F), so it sends 
> call to proxy (H). Proxy (H) sends call to proxy (E). Proxy (E) sees 
> B2BUA
> (F) is overloaded, so it releases call with 503 to proxy (H). Proxy 
> (H) sends
> 503 back to UA (B). UA (B) fails the call back to the PSTN. 
> 
This is actually the correct behavior since F has reported overload to
its upstream neighbors.

I think what you are trying to do is to optimize the protocol in a
certain scenario. My concern is that such an optimized solution will end
up being incredibly complex and very hard to get right and to manage.

Thanks,

Volker

> As you can see from this simple example, if B2BUA (F) load had been 
> relayed back to UA (B), UA (B) could have applied a gapping algorithm 
> to the call to avoid even trying to reach the B2BUA (F). It becomes 
> even more important when there are multiple UA (B) that could send to 
> the B2BUA (F), because then each UA can apply a gapping algorithm 
> independently in order to alleviate the load on the B2BUA (F). Without

> knowing the load of the B2BUA (F), you effectively create a domino 
> affect such that as more calls come in, the network will offer more 
> calls to the downstream proxies fronting the B2BUA (F), which will 
> eventually overload one or both downstream proxies. The proxy (C) will

> then start gapping calls to each proxy (D/E), until the proxy (C) 
> becomes overloaded. At this point, the UA (B) can start call gapping 
> to alleviate the proxy (C). Once proxies
> (C/H) are no longer overloaded, UA (B) will start sending to proxy (C)

> again. The proxies (D/E) may still be overloaded. If so, the proxy (C)

> will eventually go back into an overloaded state.
> 
> As you can see, the hop by hop didn't really help with overload 
> condition. In fact, it compounded the problem by overloading 
> intermediate elements that would not have become overloaded if each 
> element had relayed the B2BUA (F) load to UA (B).
> 
> A real world example of this behavior is for a Customer that offers 
> Pre-Paid Calling Card. Then a holiday like Mother's Day comes around 
> and everyone tries to use the Calling Cards that day. The B2BUA (F) 
> can only sustain 1000 calls simultaneously, but the company has sold a

> million cards. For the 3 minutes a call is up, B2BUA (F), proxies 
> (D/E), proxies (C/H), or UA (B) gap the calls. However, calls continue

> to arrive at many UA's (B) across the country as the 900,000 callers 
> that haven't gotten through continue to hit redial on their PSTN 
> phones. This one event has overloaded the Customer B2BUA (F) and 
> proxies (D/E). This application in addition to other traffic have
overloaded the proxy (C).
> It may even be overloading many UA's (B). However, if all UA's (B) had

> known how busy the B2BUA (F) was, each UA (B) could have 
> alleviated/avoided overloading the UA (B), proxies (C/H), and proxies 
> (D/E). UA (B) could have also freed up the PSTN circuits quicker, 
> which may have resulted in calls to other destinations that would have

> prevented the PSTN from offering as many calls to the overloaded B2BUA

> (F).
> 
> Rich Terpstra
>  
> Level 3 Communications
> Softswitch Architecture
> 1025 Eldorado Blvd, Broomfield, CO, 80021
> Office: (720) 888-2994

-- 
Volker Hilt                      Bell Labs / Lucent Technologies
phone: +1 732 332 6432           101 Crawfords Corner Rd
email: [email-masked]     Holmdel, NJ 07733

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 28 Jul 2006 11:14:42 -0400

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

I absolutely agree that it is best to stop a  call that can't complete as
early as possible.

However, "not being able to complete" is far more likely to be because of a
shortage of transmission resources (e.g., bandwidth, circuits at the
gateway) than a shortage of processing resources at the SIP device.

This group of IDs are focused JUST on (processing related) congestion in
the SIP device.  NOT congestion related to bandwidth.circuits, or
congestion at the end device.

That is why I found this comment a bit odd:

"The B2BUA (F)  can only sustain 1000 calls simultaneously, but the company
has sold a million cards."

The call only imposes processing load on the B2BUA when setting up or
tearing down the call. It doesn't impose processing load just to "sustain"
the call, so the number of simultaneous calls isn't likely to be an
important factor in triggering these overload messages.

If there is a limit on the number of simultaneously ACTIVE calls, whether
because of bandwidth restrictions, or logical restrictions in the SIP
device, I think that a 488 (Not Acceptable Here) response  (with the
appropriate warning code) is what would be needed in your example.

Janet

"Terpstra, Rich" <[email-masked]> wrote on 07/28/2006 10:48:42

---

From: Volker Hilt <[email-masked]>
Date: Fri, 28 Jul 2006 14:26:05 -0400

> congestion at the end device.
You are raising an interesting point about the scope of overload 
control. I agree that the focus is to deal with a shortage of resources 
in a SIP device that prevents the device from processing all incoming 
requests. I think this should includes SIP proxies as well as SIP UAs 
(e.g. a SIP registrar that reports overload when it can't handle all 
REGISTER requests).

I don't quite understand where you draw the line between processing and 
non-processing related congestion or between congestion in network and 
end-devices? What happens if the congestion in the registrar is in fact 
caused by a slow back-end database? What if a PSTN gateway runs out of 
circuits? What if a VM server is overloaded?

> appropriate warning code) is what would be needed in your example.
Yes, media bandwidth restrictions and local policies are outside the 
scope of overload control and should be dealt with through the 
respective response codes.

Thanks,

Volker

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 28 Jul 2006 15:21:33 -0400

I was basing my distinction on what constitutes  SIP processing
overload,and  what constitutes bandwidth/trunk overload, on section 4.6.5
of RFC 4412
"4.6.5.  Insufficient Resources

   Insufficient resource conditions can occur on proxy servers and user
   agent servers, typically trunk gateways.
...
   A request can fail
   because the RP actor has either insufficient processing capacity to
   handle the SIP request or insufficient bandwidth or trunk capacity to
   establish the requested session for session-creating SIP requests.

   If the request fails because the RP actor cannot handle the signaling
   load, the RP actor responds with 503 (Service Unavailable).

   If there is not enough bandwidth, or if there is an insufficient
   number of trunks, a 488 (Not Acceptable Here) response indicates that
   the RP actor is rejecting the request due to media path availability,
   such as insufficient gateway resources.  In that case, [RFC3261]
   advises that a 488 response SHOULD include a 'Warning' header field
   with a reason for the rejection; warning code 370 (Insufficient
   Bandwidth) is typical."

I was assuming that the distinction which applied to RP actors would also
apply to other SIP actors.  Maybe that was an invalid assumption. Or maybe
I am misinterpreting "signaling load".

My understanding was that the server overload requirements document was
addressing the case that  currently results in a 503: "insufficient
processing capacity to handle the SIP request".

Janet

---

From: Volker Hilt <[email-masked]>
Date: Fri, 28 Jul 2006 17:21:00 -0400

Janet,
> processing capacity to handle the SIP request".
I agree, the focus is clearly to address the cases of 503 responses. In 
the case of insufficient number of trunks, using 488 may indeed be the 
preferred approach since it is not the signaling capacity of the gateway 
that is overloaded. Thus, the gateway is still able to reject the calls 
it can't serve via a 488. Only if the load increases to a point where it 
can't reject messages properly, the gateway would need to engage 
overload control (which then seems perfectly fine).

Thanks,

Volker