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

From: "Daryl Malas" <[email-masked]>
Date: Mon, 18 Aug 2008 10:06:30 -0600

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:[email-masked]
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Daryl Malas" <[email-masked]>
Date: Mon, 18 Aug 2008 10:21:04 -0600

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

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Daryl Malas
> Sent: Monday, August 18, 2008 10:07 AM
> To: [email-masked]
> 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.
> (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
> 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 
> 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
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 18 Aug 2008 11:19:15 -0500

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Daryl Malas
Sent: Monday, August 18, 2008 11:07 AM
To: [email-masked]
Subject: [Sipping] Overload work...lost in the ether?

All,

Regards,

Daryl

----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:[email-masked]
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 18 Aug 2008 11:19:55 -0500

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

Thanks,
Mary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Daryl Malas
Sent: Monday, August 18, 2008 11:21 AM
To: [email-masked]
Subject: Re: [Sipping] Overload work...lost in the ether?

Regards,

Daryl

----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199

> this problem was first brought up in the working group in February 
> 2006 (nearly 2.5 years ago) 
> (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.
> (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:
> 

> 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.

---

From: "Daryl Malas" <[email-masked]>
Date: Mon, 18 Aug 2008 10:35:41 -0600

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) +1 303 661 3302
(f) +1 303 661 9199

> From: Mary Barnes [mailto:[email-masked]] 
> Sent: Monday, August 18, 2008 10:19 AM
> To: Daryl Malas; [email-masked]
> 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? 
> 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
> 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.