Subject: Re: [Sipping] new draft on overload control in SIP

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Jun 2006 15:35:01 -0400

Sorry for not having responded to these comments.

Samir Srivastava wrote:
> Hi,
> 
> Some comments 
> 
> 1. REQ 8 is written with view of binary overload state. Once the request
> is rejected by overloaded SIP Entity, It should not be attempted for the
> Server Entity with same or greater % of overloaded SIP entity. It
> applies to REQ 9 too. 

fixed.

> 
> 2. How does this work will be related to Event Throttling work ? 

They are different. The event throttling is unrelated to load on the 
server; its meant to reduce load on the subscriber.

> 
> 3. It needs to captured calls which are accepted before the overload
> condition how they will be treated when overload occurs, in terms of
> reINVITE  etc ?

I have added a requirement that talks about this; generally speaking, it 
needs to give guidance on what type of mesages should be prioritized 
over others.

> 
> 4. Draft has  been talking in terms REQUEST (Title also has reqs). How
> it will be handling Response overload ? I think we need to be more
> specific in this. E.g. Bad Guy might send INVITE to different SIP
> entities giving the top via as the Server to be attacked. It will
> generate 100 Trying flood to the server, which are no where related.
> Responses are not authenticated and with TLS also, one can have trusted
> bad SIP entity. 

This attack doesn't work because of the received Via param. The client 
would need to spoof its source addresses. The attack is resolved via 
TLS. I think its an issue but its not an overload problem.

> 
>    I view Avalanche restart as DDOS. There can be other DDOS scenarios
> too. Special request such as ACK which don't have any response, needs to
> be captured. One can launch unrelated ACK flood too. 
> We should have a REQUIREMENT capturing "SIP REQ / RSP messages with or
> without ...... "

No - DDoS is different. DDoS is malicious. Here, we can design 
mechanisms that take advantage of friendly elements.

> 
> 5. In Section 5, Where REQUIREMENTS are listed, we don't see requirement
> for the  server overload
>  caused on the other Non SIP (DNS/DHCP) servers due to SIP ? SIP Servers
> are okay  to handle load, 
>  but other server fails. Whether mechanism will detect this ? Just to
> clarify whether REQ 2 covers this. It will be better if we have DNS/DHCP
> ( or SIP / Non SIP) captured in that.

Yes. The draft already mentions that capacity can be reduced due to 
non-availability of external resources. I clarified this in requirement 
2 as you suggest.

> 
> 6. How does Server Overload relate to Network Congestion ? Server
> Overload might be happening because of network congestion and in some
> scenarios server overload might cause network congestion.
> Whether mechanism to be proposed will do any help in narrowing it down
> or reconfiguration ?

The draft discusses how server overload can cause network congestion, 
leading to packet loss and to further retransmits, load, and problems. 
The opposite is also true, that network congestion can cause sufficient 
loss to look like a network element failure. This is covered by 
requirement 15; i clarified that.

> 
> 6. Nits, Figure 1 is mentioned at Page 5, but it is not there.

fixed.

>  
> 7. Overload data should be captured in MIB for performance management
> applications, or is it left for properitary interfaces ?

Out of scope for this document.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Jun 2006 15:38:42 -0400

Vijay,

Sorry for not having responded to this. There are some good suggestions 
in here and they were included into the revised draft that I submitted. 
Some responses below.

Vijay K. Gurbani wrote:
> Jonathan Rosenberg wrote:
> 
>> Folks,
>>
>> I've just submitted an I-D on the topic of overload control in SIP. 
>> Until it appears in the archives, you can pick it up at:
>>
>> http://www.jdrosen.net/papers/draft-rosenberg-sipping-overload-reqs-00.txt 
>>
>>
>> The draft talks about the general problem of overload, and points out 
>> some serious problems with the current 503 mechanism. In particular, 
>> the current mechanism can amplify network load substantially during 
>> periods of overload. The draft calls out requirements for a solution.
>>
>> I believe this is an important topic. Comments are welcome.
> 
> 
> Jonathan: This is a long time in the making.  A few observations
> on what we've seen in deployments; this may trigger more requirements.
> 
> One, in some networks, we've seen the opposite of what you have
> in Figure 2.  That is, P1 (or a load distributer or a SBC) views S1
> through S3 as one logical node.  So, even if S1 issues a 503/R-A, it
> considers the whole cluster busy and will not send traffic to
> S2 and S3.  It seems appropriate to have a requirement that
> load balancers should have a more granular view on the downstream
> elements that it is distributing the load to.

Excellent point. I added a use case for this as a problem, and added a 
requirement that its unambgious to what element an overload indication 
applies.

> 
> Second, we have observed beneficial results if certain requests are
> allowed, even during overload conditions.  Specifically, requests
> like BYEs, (gulp) CANCELs, and SUBS w/ Expires=0 since these tend
> to free up resources on the overloaded host.  Thus, another
> requirement may be along the lines of an overloaded host may
> processing a request if that request frees up resources.

Added a requirement that the specification give implementation guidance 
on this.

> 
> And finally, when a mechanism is put in place, it should be of
> MUST strength.  One of the problem we've faced is that many
> implementations do not implement 503/R-A since it is a SHOULD
> strength.  Some implementations that honor it tend not to send a
> request in the same *dialog* to the overloaded host, but have no
> such qualms on sending *new* requests to the overloaded host.
> Thus, another requirement -- as transparent as it sounds -- may be
> the fact that overloaded condition applies to an entire host and
> not a transaction or dialog targeted to that host.  As a corollary,
> a request that free's up resources on the overloaded host may be
> allowed (account for the requirement in the previous paragraph).

Well, a spec can't ever mandate that it be implemented, so I dont know 
what to do here.

Thanks,
Jonathan R.