Re: [Sipping] Overload work...lost in the ether?

Correction to my post below...I just read Mary's recent email (8/16)
that the new design team draft is being considered as a working group
item; however, I am still concerned about the inclusion of a solution,
and not simply discussion on identifying overload scenarios and a
mechanism to report on the problem.

Regards,

Daryl

----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:d.malas@cablelabs.com

> -----Original Message-----
> From: sipping-bounces@ietf.org 
> [mailto:sipping-bounces@ietf.org] On Behalf Of Daryl Malas
> Sent: Monday, August 18, 2008 10:07 AM
> To: sipping@ietf.org
> Subject: [Sipping] Overload work...lost in the ether?
> 
> All,
> 
> I am a little concerned based on the decisions made in the 
> Sipping WG session in Dublin regarding the overload work.  If 
> we take a look back this problem was first brought up in the 
> working group in February 2006 (nearly 2.5 years ago) 
> (draft-rosenberg-sipping-overload-reqs-00).  The first draft 
> (draft-hilt-sipping-hopbyhop-overload-00) providing a 
> potential track towards a solution was introduced in June 
> 2006.  Then, the working group decided to create a design 
> team to look into the problem and come up with a solid 
> feedback mechanism and prove the mechanism worked by 
> describing potential solutions.  This design team has been 
> meeting at least since February 2007.  At IETF 70 
> (Vancouver), the design team reported some significant 
> improvements to the overload problem using some unique 
> algorithms provided by members of the team.
> Now, fast forward to IETF 72 in Dublin, Volker introduced a new draft
> (draft-hilt-sipping-overload-design-00) based on the work of 
> the design team.  I believe (correct me if I am wrong) the 
> response from the working group and working group chairs was:
> 
> - The design team should keep working on a "non-working group 
> item" as it is important
> - Identify a control and feedback mechanism
> - Do NOT come up with any solutions for the problem
> - Continue to provide feedback of work to the working group (for how
> long?)
> 
> I think we are missing the point related to this draft across 
> the industry.  When a problem such as this is introduced into 
> the IETF, it is introduced because the problem *exists* 
> across the industry.  The industry essentially is asking for 
> the IETF to *solve* the problem....or, come up with an 
> industry standard "solution" to the problem.  This way, 
> whether I am using vendor x, y, or z; all of them will 
> understand and react to overload control in a similar manner 
> to provide the most optimal throughput.  (I am not saying 
> enhancements/improvements may not be vendor specific ("Our 
> solution is better than vendor "y's", because it 
> provides...blah."), but at least there is a baseline solution 
> that can be standardized across the
> industry.)
> 
> IMO, here is what will occur based on this response (and, is 
> probably already occurring).  Vendors and SSPs will come up 
> with there own solutions to the problem.  When the IETF 
> finally releases something to the industry, either no one 
> will implement it (already using vendor solutions x, y, 
> and/or z), or it will be completely obsolete because some 
> other solution (e.g. SBC session limiting functionality) has 
> resolved (while maybe non-optimally) the problem.
> 
> I just wanted to provide some feedback and encourage the 
> Sipping WG and the overload design team to continue working 
> aggressively to provide a mechanism to report overload and a 
> baseline solution to resolve it, or provide a statement 
> describing why the problem does not (or should not) exist.
> 
> Regards,
> 
> Daryl
> 
> 
> ----------------
> Daryl Malas
> CableLabs
> (o) +1 303 661 3302
> (f) +1 303 661 9199
> mailto:d.malas@cablelabs.com
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP 
> Use sip-implementors@cs.columbia.edu for questions on current 
> sip Use sip@ietf.org for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP