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

From: "CHADLI Youssef RD-CORE-ISS" <[email-masked]>
Date: Thu, 24 May 2007 15:22:31 +0200

I have proposed to add two kinds of requirements for which the use of a new header to carry load information could not satisfy:
 
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  

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.  

Best regards

Youssef C. 

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

---

From: Volker Hilt <[email-masked]>
Date: Thu, 24 May 2007 11:47:43 -0400

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.

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

> 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