[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