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

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

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