Subject: RE: [Sipping] WGLC: draft-ietf-sipping-overload-reqs-00.txt

From: "CHADLI Youssef RD-CORE-ISS" <[email-masked]>
Date: Fri, 25 May 2007 15:52:21 +0200

Inline 
 
> De : Volker Hilt wrote:	
> CHADLI Youssef RD-CORE-ISS wrote:
> > I have proposed to add two kinds of requirements for which 
> the use of 
> > a new header to carry load information could not satisfy:
> > 
> I think these requirements are somewhat dubious and seem to 
> be tailored to support a certain solution. I haven't seen a 
> conclusion on the list that they are generally needed.

I haven't seen an opposition to these requirements on the mailing list. Jonathan has proposed a text for the first one. These requirements are not destined to support a specific solution. However, I do believe that using a new SIP header to carry load information may be not the good solution. I do not think that rejecting requirements because they may not be satisfied by a solution we have in mind would be a good think. I think that section "3.7 SIP mechanisms" in draft-hilt-sipping-overload needs be more discussed.

> > 1) The overload mechanism must allow preventing load 
> information to be 
> > sent to untrusted elements, for the following reasons:
> > - Providing
> > load information to malicious elements amplifies the 
> malicious attacks 
> > risks towards SIP servers: In fact, load information can be used by 
> > malicious element to detect the servers' weaknesses. For
> > instance: one of DOS attacks consists on overloading the server. If 
> > one wants to overload a given Server it needs to generate more 
> > messages than the server can treat. An almost overloaded server has 
> > less available resources (CPU, memory, disk space ...etc), 
> then there 
> > is no need to have a very powerful machine to get such a server 
> > completely overloaded.
> > - For confidentiality reasons, a service provider may do no 
> want that 
> > an untrusted service provider knows the load level of its servers.
> > 
> > To meet this requirement, the mechanism must guarantee tow things: 
> > a) The SIP server must be able to identify the server to witch it 
> > sends the load information
> > b) The SIP server must have the guarantee that this server will not 
> > forward this information to other elements.
> > 
> > 2) It must be possible to support the overload mechanism by SIP 
> > servers implemented as a farm of servers without implying 
> big impacts 
> > on the performance of the front-ends servers managing the farm:
> > a) The mechanism must not require front-ends parsing all received 
> > messages to look for overload control information.
> > b) The mechanism
> > must not require front-end servers to open messages sent by 
> > applications to insert overload control information
> > c) The mechanism
> > must support aggregating load information from different 
> elements of a 
> > server farm
> > 
> Others have said this before and I also don't understand how 
> this is going to work. It seems to require that load balanced 
> proxy farms are somehow not allowed to look into the SIP 
> messages they process.

In case of a SIP server composed of a farm of servers with a front-end server, only this latter knows the load status of the whole server. Two cases are possible:
 -  The front-end server performs only load balancing of initial SIP request between the managed servers of the farm and, for performance reasons, it does not want to receive the subsequent messages (including the SIP responses), then using SIP responses to carry load information would not work with this kind of servers. 
 - The front-end server does load balancing and performs some other functions which imply that it receives all the SIP messages. In this case, in general, the frond-end server would just need to relay these messages. If the load information are exchanged in SIP responses, such frond-end server has to check all received SIP responses from external SIP severs to extract the possible load information. Moreover, the front-end server has to intercept SIP responses coming from the fed servers to insert load information destined to external servers. Consequently, supporting this mechanism by such SIP servers would heavily impact their performance.

Using dedicated SIP messages, outside of "normal" SIP dialogs and transactions, is more suitable in this case.

> > I think that these requirements are important and should be 
> included 
> > in the draft.
> > 
> > According to the discussion we have had on the mailing list, it 
> > appears that the use of a new SIP header to carry load information 
> > would not allow satisfying such requirements. I believe 
> that using a 
> > dedicated SIP messages such as Subscribe/Notify (with a new event
> > package) seems to be a more suitable solution. Hence, this draft 
> > should only focus on requirements definition without 
> imposing the way 
> > to be used for load information exchange which should be 
> discussed in 
> > the solution document.
> > 
> I agree with our last sentence. However, it seems to 
> contradict what is said before. Overall, I think this 
> discusses alternatives for a solution instead of requirements 
> for an overload control mechanism.

> 
> Volker
> 
> 
> 
> 
> 
> 
> >> -----Message d'origine----- De : Mary Barnes 
> >> [mailto:[email-masked]] Envoyé : lundi 21 mai 2007 23:12 À
> >> : [email-masked] Cc : [email-masked] Objet : [Sipping] WGLC:
> >> draft-ietf-sipping-overload-reqs-00.txt
> >> 
> >> Draft: draft-ietf-sipping-overload-reqs-00 Reviewer: Mary Barnes 
> >> Review Date: May 21, 2007 Review Deadline: May 21, 2007 Status:
> >> WGLC
> >> 
> >> Summary: This draft is basically ready for publication, 
> but has nits 
> >> that should be fixed before publication.
> >> 
> >> Nits: - Need to add the Intended Status to the header:
> >> category="info" - Section 6 (General):  I agree with Volker's 
> >> suggestion that this section should match the agreed modeling 
> >> approach from the design team - Section 6.1: qualifying the 
> >> parameters in section 6 with the units would make it more readable 
> >> (e.g., "Saccess" -> "Saccess bits" and "Score" -> "Score bits") - 
> >> Section 6.3: per comment above on 6.1, "Srin" -> "Srin 
> bits" - Figure 
> >> 6: "Spkit" -> "Spkt"  (or change the reference in 6.2 to
> >> "Spkit")
> >> 
> >> 
> >> _______________________________________________ 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
> >> 
> > 
> > 
> > _______________________________________________ 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
> 
> 
> 

_______________________________________________
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: Volker Hilt <[email-masked]>
Date: Fri, 25 May 2007 11:58:15 -0400

CHADLI Youssef RD-CORE-ISS wrote:
> I haven't seen an opposition to these requirements on the mailing 
> list. Jonathan has proposed a text for the first one. These
> requirements are not destined to support a specific solution.
> However, I do believe that using a new SIP header to carry load
> information may be not the good solution. I do not think that
> rejecting requirements because they may not be satisfied by a
> solution we have in mind would be a good think. 

I think we are still in the process of figuring out what a good solution 
is and should not block one way or the other.

> I think that section
> "3.7 SIP mechanisms" in draft-hilt-sipping-overload needs be more
> discussed.
>
All comments and input is certainly very welcome.

> In case of a SIP server composed of a farm of servers with a 
> front-end server, only this latter knows the load status of the whole
> server. Two cases are possible: 
>  - The front-end server performs only
> load balancing of initial SIP request between the managed servers of
> the farm and, for performance reasons, it does not want to receive
> the subsequent messages (including the SIP responses), then using SIP
> responses to carry load information would not work with this kind of
> servers. 

What you are talking about seems to be a third party that does not 
participate in SIP signaling but implements overload control on behalf 
of the proxies in the farm.

Having such an overload box will require this box to receive the 
overload status from all proxies (maybe through subscriptions?). 
Upstream neighbors would have to have a way to discover the overload box 
that is responsible for a server, subscribe to load status and get 
notifications. The box would have to manage subscriptions over time to 
all its upstream neighbors.

> - The front-end server does load balancing and performs some
> other functions which imply that it receives all the SIP messages. In
> this case, in general, the frond-end server would just need to relay
> these messages. If the load information are exchanged in SIP
> responses, such frond-end server has to check all received SIP
> responses from external SIP severs to extract the possible load
> information. Moreover, the front-end server has to intercept SIP
> responses coming from the fed servers to insert load information
> destined to external servers. Consequently, supporting this mechanism
> by such SIP servers would heavily impact their performance.
> 
This server would need to do the usual SIP header processing and 
modification. I don't see what load information would add that would 
heavily impact their performance.