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

From: "Darshan Bildikar" <[email-masked]>
Date: Thu, 3 May 2007 09:21:17 +0530

I had asked a while ago whether load to a particular "service" can
controlled. 

I see a use case for throttling the traffic to a box running multiple
services. 

I wonder now, if this can be tied to
"draft-rosenberg-sipping-service-identification" and we can have a
requirement that enables overload control based on service URN. (Adding to
REQS 18 and 19)

Darshan

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: Tuesday, May 01, 2007 1:50 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Sipping] WGLC: draft-ietf-sipping-overload-reqs-00

Hi all,

This is to announce Working Group Last Call on the following document:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-overload-reqs-00.
txt

This WGLC will end on 21 May 2007.

There were a few comments on this document already that can be
incorporated with last call comments, but we would like 3 volunteers to
commit to reviewing the document in detail.  If interested, please let
us know.  

As always, anyone else that gets a chance to review should also send
their feedback to the authors and copy the SIPPING mailing list.  

Thanks, 
Mary 
SIPPING WG co-chair

_______________________________________________
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: "CHADLI Youssef RD-CORE-ISS" <[email-masked]>
Date: Wed, 30 May 2007 11:07:31 +0200

> Jonathan Rosenberg wrote:

> > Another argument in favour of controlling the access to the load 
> > information is that for confidentiality reasons, a service provider 
> > may do no want that an untrusted service provider  knows the load 
> > level of its servers.
> 
> I'm OK with a requirement around this point speifically. I do 
> understand that service providers view the load on their 
> network overall as proprietary. The simple answer, of course, 
> is that you are always free to not implement this extension 
> towards proxies outside of your domain. 
> If you want to capture that in a requirement, how about:
> 
> REQ XX: It must be possible to disable the reporting of load 
> information towards upstream targets based on the identity of 
> those targets. Of course, in such cases, there is no 
> expectation that the overload mechanism itself will help 
> prevent overload from that upstream target.

The way this requirement is written is tailored to the use of a new
header in SIP responses to carry load information feedbacks. In order to
let the door open to discuss other alternatives (such as use of
Subscribe/Notify mechanism), I propose to rewrite this requirement to
something like:

REQ XX: It must be possible to prevent untrusted elements to access load
information of SIP servers. Of course, in such cases, there is no
expectation that the overload mechanism itself will help prevent
overload from these elements.

> I'd propose:
> 
> REQ XX: It must be possible for the overload mechanism to 
> work in cases 
> where there is a load balancer in front of a farm of proxies, 
> and that 
> load balancer tracks the state of the nodes in the cluster, 
> and actually 
> implements the overload mechanism.

I am OK with this requirement.

Best regards,
Y. CHADLI