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

["Daryl Malas" <[e-mail]>]

Mary,

Thank you for providing your perspective.  You definitely can consider
my feedback a "raised hand" for volunteering to review the draft.  I
hope you do not misunderstand my comments as complaining about the draft
w/o providing any real constructive feedback.  I will provide that
secondarily.  My email was intended to provide encouragement for the
working group to continue the efforts as aggressively as possible.  I
think this problem needs to be resolved and a solution to the problem
will provide *real* value to the industry, today.  I just do not want to
see this work turn into some of the other IETF solutions, which took
more time than the industry was willing to wait for; and, when a
solution was finally presented many had already moved on with
alternative solutions.

Regards,

Daryl


----------------
Daryl Malas
CableLabs
(o) [phone]
(f) [phone]
mailto:[e-mail]
 

> -----Original Message-----
> From: Mary Barnes [mailto:[e-mail]] 
> Sent: Monday, August 18, 2008 10:19 AM
> To: Daryl Malas; [e-mail]
> Subject: RE: [Sipping] Overload work...lost in the ether?
> 
> Hi Daryl,
> 
> Did you have a chance to look at the minutes of the IETF-72 
> SIPPING WG session? 
> http://www.softarmor.com/sipping/meets/ietf72/notes/sipping-72
> -minutes.t
> xt
> 
> The folks involved are working as aggressively as possible 
> (given the limitations of the people involved and relative to 
> other work in the RAI
> area) and have all invested a significant amount of time in 
> the activity over the past couple of years - . I can give you 
> lots of examples of other very important work in terms of the 
> industry that has progressed
> far more slowly.   We do need to progress in a logical 
> manner, which is
> why the model and design considerations document is 
> important.  Given my experience, in most cases when we've 
> fast tracked things to the SIP WG, we've gotten stuck in the 
> mode of folks actually not agreeing some of the fundamentals. 
> So, I personally think it's very important that this is done 
> right and in consultation with the right experts - industry 
> and IETF (e.g., TSV). 
> 
> From my personal experience with the vendor community, you 
> are right that folks are already implementing solutions, but 
> I honestly don't think that we're nearly as far behind as 
> we've been in other areas in the past and most folks I've 
> talked to recognize the importance of doing this right - this 
> isn't just a header or event package involved - the models 
> and when folks make use of the headers, etc. is really far 
> more important. 
> 
> So, perhaps, this may sound like an excuse, but I think the 
> folks involved are doing the best they can and from a process 
> perspective.
> 
> One of the best ways to get this work done more quickly is 
> for folks to provide constructive feedback on the documents - 
> i.e., the one that we've just agreed as a WG document, so I 
> will take your message as an indicator of your volunteering 
> to be a reviewer for this doc when the -00 is submitted. 
> 
> It's also imperative for folk help us complete the other work 
> items more quickly. This really means paying attention and 
> thinking through things early on rather than waiting until 
> work is getting ready to leave the WG to make comments (and 
> in many cases reverse past WG consensus), which has been the 
> mode of operation for several of the RAI WGs many of us are 
> involved in. 
> 
> So, if folks believe this work is really important, please 
> volunteer as a reviewer and please help us complete other key 
> industry deliverables such as the profile-dataset work. 
> 
> Regards,
> Mary.
> --mostly as SIPPING WG chair, other than when I used the term 
> "personal"
> or "personally". 
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Daryl Malas
> Sent: Monday, August 18, 2008 11: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