Subject: [Sipping] Further comments on the draft-rosenberg-sipping-overload-reqs-00

From: <[email-masked]>
Date: Wed, 22 Mar 2006 21:14:07 -0000

All 

A number of comments have been generated on the solution requirements to
open discussion and are imbedded in the text below

5.  Solution Requirements

   In this section, we propose requirements for an overload control
   mechanism for SIP which addresses these problems.

   REQ 1: The overload mechanism shall strive to maintain the throughput
      of a SIP at reasonable levels even when the incoming load on the
      network is far in excess of its capacity.  The overall throughput
      under load is the ultimate measure of the value of an overload
      control mechanism.
      
      [Steve] BTs view is that the overall throughput is not the
ultimate 
      measure of a control; it is the overall throughput that meets
response 
      time targets. 

   REQ 2: The failure, reduced processing capacity or overload of a
      single network element should be isolated from the remainder of
      the network, preventing a small-scale failure from becoming a
      widespread outage.
      
      [Steve] Don't understand this requirement.  Is it suggesting that 
      a failed or overload component should be disconnected from the
network? - 
      But this doesn't really help does it?  The event that causes the
overload
      will still be happening and the overload will be exported to
another network
      element. 

      Perhaps my misunderstanding is that it means that the consequent
events 
      should be isolated - but then how is emergency comms etc.
supported? Is this 
      aiming at the same requirement 7 of ETSI GOCAP requirements draft
"automatically 
      limit ineffective service requests by detecting specific called
names/addresses
      that are attracting a high reject rate and selectively controlling
demand to them"?

   REQ 3: The mechanism should seek to minimize the amount of
      configuration required in order to work.  For example, it is
      better to avoid needing to configure a server with its SIP message
      throughput, as these kinds of quantities are hard to determine.

      [Steve] Agreed I don't think it is necessarily useful to
statically 
      define server capacity  anyway - probably best to generate the
data 
	dynamically, because it changes when the message type mix
changes.  
	In general we are trying to optimise the server capacity, so
some 
	target parameters will be needed - e.g. target CPU utilisation
or 
	target response time etc.

   REQ 4: The mechanism must be capable of dealing with elements which
      do not support it, so that a network can consist of a mix of ones
      which do and don't support it.  Ideally, there should be
      incremental improvements in overall network throughput as
      increasing numbers of elements in the network support the
      mechanism.

	[Steve] From the discussion of REQ 1, I have assumed that if you
want
	to be able to survive larger overloads, or manage the workload
better, 
	you need remote restrictions.  This implies, at a minimum, that
sources 
		implement the restriction as part of the control. 

		However where some sources do not support overload by
implementing 
		restrictors on the overloaded target - this helps to
prevent sources not 
		equipped with overload control from stealing all the CPU
resource 
		from those that do.

		In summary, you can only really meet REQ 1, maximise
throughput, if all 
		sources implement remote restrictors.  If they don't,
you will inevitably 
		move off the peak throughput as you expend additional
effort rejecting 
		extra traffic from unrestricted sources.  You have to do
this, or you will 
		starve the sources that do implement the distributed
control and your 
		response times will get too long

   REQ 5: The mechanism should function in an environment where an
      upstream element is malicious and attempting to fool the system
      into believing it is overloaded when its not, and vice a versa.

		[Steve] Any distributed overload control relies on a
certain degree 
		of trust; which implies that the sources are trusted
that they will 
		implement any restriction honestly.  

		At the moment I can't see why an upstream server would
benefit from
		pretending it is overloaded when it isn't - but I'm no
security expert.  

		I think any overload scheme has to accept that if a
server says you 
		should back off - then you back off.  

		What is needed is a mechanism to verify that the
congestion control 
		messages are actually from the server they claim to be
from, and 
		that the effect of those messages is to manage load to
that source 
		server - not someone else's server! 

   REQ 6: The mechanism shall provide a way to unambiguously inform an
      upstream element that it is overloaded, as distinct from other
      temporary failure conditions.

		[Steve] Not sure on this requirement, an overload
indication is a 
		overload indication so is fairly unambiguous, and what
do you do when 
		the overload is due to the Temporary failure, and in
this case why 
		not send both indications? 

   REQ 7: The mechanism shall provide a way for an element to throttle
      the amount of traffic it receives from an upstream element.  This
      throttling shall provide the ability to reduce the traffic in
      incremental percentages from 0 to 100%.  This recognizes the fact
      that "overload" is not a binary state, and there are degrees of
      overload.

		[Steve] Agreed that servers need to be able to throttle
sources 
		But I strongly disagree with the reference the
percentage restrictor - 
		this is a potential solution not a requirement. 

		The actual requirement is that an overloaded server can
signal 
		congestion information to its sources and that the
sources can use 
		that information to take appropriate action. 

		(In any case BT would rather that an arrival rate or
workload rate 
		was specified but this can be argued about later)

   REQ 8: The mechanism shall ensure that, when a request has been
      rejected from an overloaded element, it is not sent to another
      overloaded element for processing.  This requirement derives from
      REQ 1.

	[Steve] Agreed however does the node trying to deliver a request

		keep trying forever or should there be a limit to the
number of 
		attempts or a timeout?

   REQ 9: When a request has been rejected from an overloaded element,
      it is not sent to another overloaded element for processing, but
      can be sent to one that is known to be available (i.e., not
      overloaded).  This requirement derives from REQ 1.

		[Steve] Agreed however should the application employing
SIP session 
		also have a impact upon this decision

   REQ 10: The mechanism should support servers that receive requests
      from a large number of different upstream elements, where the set
      of upstream elements is not enumerable.

		[Steve] As comments in his draft acknowledge, the
existing 503 
		mechanism could work well here - if clients support it
properly. 
		However if you consider this requirement with REQ 4,
there may be 
		some problems.  If you are not very careful, partial
deployment of 
		controls among a very large numbers of sources means
that you 
		effectively punish control equipped sources as they will
forced 
		to back off when the uncontrolled sources will not. 

   REQ 11: The mechanism should support servers that receive requests
      from a finite set of upstream elements, where the set of upstream
      elements is enumerable. [Steve] Agree

   REQ 12: The mechanism should work between servers in different
      domains. [Steve] Agree

   REQ 13: The mechanism must allow a proxy to prioritize requests, so
      that certain ones, such as call for emergency services, are still
      processed. [Steve] Agree

   REQ 14: The mechanism should provide unambigous directions to clients
      on when they should retry a request, and when they should not.
      This especially applies to TCP connection establishment and SIP
      registrations, in order to mitigate against avalanche restart.

		[Steve] I am not sure that I fully understand this, will
the server 
		send a different overload message depending on the
transport deployed?

   REQ 15: The mechanism shall take into account failures of downstream
      elements, detected either through SIP or through out-of-band
      means, in which case congestion indications will not be sent.

		[Steve] Not sure I understand this. If a server is
overloaded, 
		then it is appropriate to signal that, regardless of the
cause.

   REQ 16: The mechanism should attempt to minimize the overhead of the
      overload control messaging. [Steve] Agree

   REQ 17: The overload mechanism must not provide an avenue for
      malicious attack. [Steve] Agree

Regards

Steve 

The ETSI GOCAP draft is available at
http://portal.etsi.org/docbox/TISPAN/Open/NGN%20LATEST%20DRAFTS/02026v00
6.pdf as I have had a number of requests for a copy of this draft. 
_______________________________________________
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: Wed, 22 Mar 2006 16:55:18 -0500

Comment in line below.

Janet

             <steve.norreys@bt                                             
             .com>                                                         
                                                                        To 
             03/22/2006 04:14          <[email-masked]>,                 
             PM                        <[email-masked]>                 
                                                                        cc 
                                                                           
                                                                   Subject 
                                       [Sipping] Further comments on the   
                                       draft-rosenberg-sipping-overload-re 
                                       qs-00                               

                                                                           

      [Steve] Agreed I don’t think it is necessarily useful to statically
      define server capacity  anyway – probably best to generate the data
        dynamically, because it changes when the message type mix changes.

        In general we are trying to optimise the server capacity, so some
        target parameters will be needed – e.g. target CPU utilisation or
        target response time etc.

[Janet] Or queue length, or time in queue.  With any of these, there needs
to be some sort of moving average and/or hysteresis, so the system doe not
"thrash" between "congested"/"non congested" states.

---

From: "Dale R. Worley" <[email-masked]>
Date: Thu, 30 Mar 2006 21:46:57 -0500

I think I can make clearer some of the requirements in this draft.

On Wed, 2006-03-22 at 21:14 +0000, [email-masked] wrote:
>       [Steve] BTs view is that the overall throughput is not the ultimate  
>       measure of a control; it is the overall throughput that meets response  
>       time targets.

Perhaps a way to consolidate these statements would be "The overall
useful throughput (taking into consideration the quality-of-service
needs of the using applications) is the ...".  Response time is one
requirement that some applications have, but other applications have
different requirements and are relatively insensitive to response time.

>       [Steve] Don’t understand this requirement.  Is it suggesting that  
>       a failed or overload component should be disconnected from the network? –  
>       But this doesn’t really help does it?  The event that causes the overload 
>       will still be happening and the overload will be exported to another network 
>       element.

What he means is "the *effects* of the failure, reduced processing
capacity, or overload of a single network element should be isolated (as
much as possible) from ...".  Actually, I think I've got the phrasing
backward, it's more like "The rest of the network shall be isolated from
the effects..."

>         [Steve] From the discussion of REQ 1, I have assumed that if you want 
>         to be able to survive larger overloads, or manage the workload better,  
>         you need remote restrictions.  This implies, at a minimum, that sources  

That's an assumption.  In an ideal world, adding overload control to one
element alone will improve the overall performance of the network.  (Of
course, if multiple elements have overload control, they may
synergisticly improve the overall performance of the network much more.)
But the mechanism should not *depend* on other elements implementing it
to generate any benefit.

>                 [Steve] Any distributed overload control relies on a certain degree  
>                 of trust; which implies that the sources are trusted that they will  

Again, this is an assumption of networks that have centralized
administration, but the existence of networks with decentralized
administration shows that is not absolutely necessary.

>                 At the moment I can’t see why an upstream server would benefit from 
>                 pretending it is overloaded when it isn’t - but I’m no security expert.  

Unfortunately, for some attackers, merely damaging the capacity of the
network is a goal.

>                 [Steve] Not sure on this requirement, an overload indication is a  
>                 overload indication so is fairly unambiguous, and what do you do when  
>                 the overload is due to the Temporary failure, and in this case why  

One could argue that there is no "indication of temporary failure",
since a failed element ipso facto can send no indication of its state!

But I think it could be argued that this should not be a requirement.
It is likely that this would be a useful feature of almost any high-
quality mechanism, but I see no reason why this is a requirement in and
of itself.

>       that "overload" is not a binary state, and there are degrees of 

It seems to me that this is really a recognition that we want a
mechanism more nuanced than "send/do not send", that the latter would
likely produce a user experience significantly worse than what an
overloaded system could ideally provide.  But the choice of "incremental
percentages" per se is not a requirement.

>                 [Steve] Agreed however should the application employing SIP session  

I think that what this requirement is working for is "That a request has
been rejected from an overloaded element shall not unduly restrict the
ability of that request to be submitted to and processed by an element
that is not overloaded."

>                 [Steve] As comments in his draft acknowledge, the existing 503  
>                 mechanism could work well here – if clients support it properly.  
>                 However if you consider this requirement with REQ 4, there may be  
>                 some problems.  If you are not very careful, partial deployment of  
>                 controls among a very large numbers of sources means that you  
>                 effectively punish control equipped sources as they will forced  

It seems like you've identified a new requirement:  "In a mixed
environment of elements that do and do not implement the overload
mechanism, no disproportionate benefit shall accrue to the users or
operators of the elements that do not implement the mechanism."

Dale