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

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

Thanks for your helpful responses, Dale. Most of this made it into a 
revision I have submitted. Some responses below:

Dale R. Worley wrote:
> 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:
> 
>>   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.
> 
> 
> 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.

Good suggestion. Done.

> 
> 
>>   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.
> 
> 
> 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..."

I reworded this as:

<t hangText="REQ 2:">When a single network element fails, goes into
overload, or suffers from reduced processing capacity, the mechanism
should strive to limit the impact of this on other elements in the
network. This helps to prevent a small-scale failure from
becoming a widespread outage.  </t>

> 
> 
>>   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. 
> 
> 
> 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.

Right. Thats why the key words is "capable of dealing with". I tried to 
clarify this further.

> 
> 
>>   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.
> 
> 
> 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.

Right. I reworded towards the negative, so that its clear that the 
requirement is that you can't assume completely trusted elements.

> 
> 
>>                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.

Right.

> 
> 
>>   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? 
> 
> 
> 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.

One of the problems we've had is that folks have used the 503 response 
code for other things, such as in ISUP cause code mappings. This has 
caused deployment problems. I've tried to reword to be clearer.

> 
> 
>>   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.
> 
> 
> 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.
> 

Right. Removed percentages and just talk now about not being all or nothing.

> 
>>   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
> 
> 
> 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."

I used your suggested wording.

> 
> 
>>   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. 
> 
> 
> 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."

Yes - well said. I added that requirement.

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