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

["Mary Barnes" <[e-mail]>]

And, our emails just passed on the wire, but I think much of what I said
is still relevant.

Thanks,
Mary.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Daryl Malas
Sent: Monday, August 18, 2008 11:21 AM
To: [e-mail]
Subject: 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) [phone]
(f) [phone]
mailto:[e-mail]
 

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Daryl Malas
> Sent: Monday, August 18, 2008 10:07 AM
> To: [e-mail]
> 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) [phone]
> (f) [phone]
> mailto:[e-mail]
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP Use 
> [e-mail] for questions on current sip Use 
> [e-mail] 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
[e-mail] for questions on current sip Use
[e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP