Subject: [Dime] Fwd: New Version Notification for draft-ietf-dime-overload-reqs-02.txt

From: Ben Campbell <[email-masked]>
Date: Tue, 18 Dec 2012 17:23:29 -0600

Hi Everyone,

We've submitted draft-ietf-dime-overload-reqs-02, based on the list discussions over the last few weeks. We believe this addresses all the substantive comments so far, except for the ongoing discussion on Req2 (concerning application independence and the impact on application specifications.) We've noted the open issue for Req 2 in the text.

The new version is available at http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-02 . You can see a diff from version 01 at http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-dime-overload-reqs-02.txt .

Thanks!

Ben.

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-ietf-dime-overload-reqs-02.txt
> Date: December 18, 2012 5:19:27 PM CST
> To: [email-masked]
> Cc: [email-masked]
> 
> 
> A new version of I-D, draft-ietf-dime-overload-reqs-02.txt
> has been successfully submitted by Ben Campbell and posted to the
> IETF repository.
> 
> Filename:	 draft-ietf-dime-overload-reqs
> Revision:	 02
> Title:		 Diameter Overload Control Requirements
> Creation date:	 2012-12-17
> WG ID:		 dime
> Number of pages: 27
> URL:             http://www.ietf.org/internet-drafts/draft-ietf-dime-overload-reqs-02.txt
> Status:          http://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs
> Htmlized:        http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-02
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-overload-reqs-02
> 
> Abstract:
>   When a Diameter server or agent becomes overloaded, it needs to be
>   able to gracefully reduce its load, typically by informing clients to
>   reduce sending traffic for some period of time.  Otherwise, it must
>   continue to expend resources parsing and responding to Diameter
>   messages, possibly resulting in congestion collapse.  The existing
>   mechanisms provided by Diameter are not sufficient for this purpose.
>   This document describes the limitations of the existing mechanisms,
>   and provides requirements for new overload management mechanisms.
> 
> 
> 
> 
> The IETF Secretariat
>

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 19 Dec 2012 10:47:58 +0200

Hi Ben,

Thanks for the update. Now that the new revision is out
I would encourage the WG to sort out the language in REQ 2
asap. As long as it is in flux the document cannot proceed
to WGLC.

- jouni

On Dec 19, 2012, at 1:23 AM, Ben Campbell <[email-masked]> wrote:

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Tom Taylor <[email-masked]>
Date: Wed, 19 Dec 2012 11:04:51 -0500

I think the requirement is trying to say the following:

"Basic support for overload controls MUST be independent of what 
applications a given Diameter node supports. Individual applications MAY 
provide more refined support for overload controls."

> asap. As long as it is in flux the document cannot proceed
...

---

From: "Mark Jones" <[email-masked]>
Date: Wed, 19 Dec 2012 12:23:01 -0500

> provide more refined support for overload controls."

I'm not reading a requirement for basic vs. refined support from the current
REQ 2 text.  I understand that REQ 2 is trying to establish the bounds of
acceptable impacts on existing Diameter applications. IMHO it should read
something like "the addition of the Diameter overload control mechanism to
an existing Diameter application MUST NOT require the allocation of a new
application id". Do we need to constrain the solution any further?

I don't understand the motivation for requiring that it "MUST NOT require
specification changes for existing Diameter applications". If 3GPP decides
that Diameter overload control must be supported on an existing reference
point, I would expect the 3GPP TS for that release to be updated to state
just that. This is a "specification change" and I don't see how else a
vendor would know that they had to update their implementation. What am I
missing here?

/Mark

> > Thanks for the update. Now that the new revision is out I would
> > encourage the WG to sort out the language in REQ 2 asap. As long as it
> > is in flux the document cannot proceed to WGLC.
> >
> > - jouni
> >
> ...

---

From: Eric McMurry <[email-masked]>
Date: Wed, 19 Dec 2012 19:25:48 +0100

Hi Mark,

There wasn't a mention of basic and refined before, but I think Tom's comment was close to what the requirement was trying to get at.  It goes beyond not changing the application id.  It is entirely possible to design a mechanism that requires no action from 3GPP and the requirement was intended to ensure that the resulting mechanism is designed that way.

Thanks,

Eric

---

From: Eric McMurry <[email-masked]>
Date: Wed, 19 Dec 2012 19:26:45 +0100

Hi Mark,

Thanks,

Eric

---

From: Ben Campbell <[email-masked]>
Date: Wed, 19 Dec 2012 12:30:16 -0600

Hi Tom,

I think that's on the right track. We've been too focused on specification impact, when the root of the requirement is really a combination of application-independent default behavior, along with extensibility to allow application-specific behavior.

To put some finer points on it, how's this? I tried to take the spirit of your proposed text, and added some non-normative elaboration:

The mechanism MUST allow Diameter nodes to support default overload control regardless of which Diameter applications they support. It MUST provide sufficient extensibility to allow individual applications to provide more refined overload control.

The basic mechanism is intended to be application-independent, that is, a Diameter node can use it across any existing and future Diameter applications and expect reasonable results. Certain Diameter applications might, however, benefit from application-specific behavior over and above the mechanism's defaults. For example, an application specification might specify relative priorities of messages or selection of a specific overload control algorithm.

On Dec 19, 2012, at 10:04 AM, Tom Taylor <[email-masked]> wrote:

> "Basic support for overload controls MUST be independent of what applications a given Diameter node supports. Individual applications MAY provide more refined support for overload controls."
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 19 Dec 2012 12:40:49 -0600

Hi Mark, see comments inline:

Thanks!

Ben.

> application id". Do we need to constrain the solution any further?

The original Req 2 language clearly created confusion about it's original intent. This really is about application-independence.  I think that not forcing new application IDs is an implication of that intent, but does not capture it entirely. Please see my separate response to Tom's email.

> vendor would know that they had to update their implementation. What am I

The idea is that an implementor would not have to wait for 3GPP in order to implement whatever RFC we come up with in DIME. 3GPP could certainly require support, and specify application-specific refinements. Those would require updates to the relevant specs. But even if they didn't do that, people could still choose to support some level of overload control.

---

From: Tom Taylor <[email-masked]>
Date: Wed, 19 Dec 2012 14:51:39 -0500

Just a one-word change.

On 19/12/2012 1:30 PM, Ben Campbell wrote:
> Hi Tom,
>
> I think that's on the right track. We've been too focused on
> specification impact, when the root of the requirement is really a
> combination of application-independent default behavior, along with
> extensibility to allow application-specific behavior.
>
> To put some finer points on it, how's this? I tried to take the
> spirit of your proposed text, and added some non-normative
> elaboration:
>
>
> The mechanism MUST allow Diameter nodes to support default overload
> control regardless of which Diameter applications they support. It
> MUST provide sufficient extensibility to allow individual
> applications to provide more refined overload control.
>
> The basic mechanism is intended to be application-independent, that
> is, a Diameter node can use it across any existing and future
> Diameter applications and expect reasonable results. Certain Diameter
> applications might, however, benefit from application-specific
> behavior over and above the mechanism's defaults. For example, an
> application         might specify relative priorities of
               ^^^^^^^^
> messages or selection of a specific overload control algorithm.
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 19 Dec 2012 14:15:33 -0600

WFM

---

From: "THIEBAUT, LAURENT (LAURENT)" <[email-masked]>
Date: Wed, 19 Dec 2012 21:34:14 +0100

Hello all

Thanks Ben for the new version

I think we are approaching towards the conclusion but would like to suggest following new requirements

REQ X:   A common default algorithm to react to an overload status SHOULD be defined in order to allow a basic inter-operable inter Service Provider overload mechanism.

REQ Y:   Even though there are Diameter Agents between 2 Diameter end-points (client/server) that support the (overload control) feature, there MUST be a way to report an *overload* status to the Diameter end-points (client/server) in order for Diameter end-points to be able to take proper (possibly non Diameter) actions.

So to us, the remaining work would be on Req2, Req X and Req Y.

It is recognized that Req Y is almost the same than Req 35 but with

·         a "MUST" instead of a "SHOULD"

·         the fact that even when the DA supports the mechanism the end point may need to know an *overload* status (this may be different for a *load* status)

·         and (minor remark) the indication that the reaction to an overload status may imply possible non Diameter actions.

Best regards

Laurent

ALCATEL-LUCENT

-----Message d'origine-----

De : [email-masked] [mailto:[email-masked]] De la part de Jouni Korhonen

Envoyé : mercredi 19 décembre 2012 09:48

À : Ben Campbell

Cc : [email-masked]

Objet : Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt

Hi Ben,

to WGLC.

- jouni

DiME mailing list

[email-masked]

---

From: "Mark Jones" <[email-masked]>
Date: Wed, 19 Dec 2012 15:38:53 -0500

Hi Eric,

> There wasn't a mention of basic and refined before, but I think Tom's
> comment was close to what the requirement was trying to get at.  It goes
> beyond not changing the application id.  

If I've understood correctly, REQ2 was originally intended to capture the
requirement for an application-neutral overload control mechanism. The
support for application-specific extensions for overload control is a new
requirement that has come out of discussions of the original REQ2 text. Just
to be clear, I'm not arguing against either requirement. I just couldn't
derive the new requirement from reading revision -02.

> It is entirely possible to design a
> mechanism that requires no action from 3GPP and the requirement was
> intended to ensure that the resulting mechanism is designed that way.
> 

I understand the design goal but I think you missed the point of my 3GPP
example. You can certainly design the mechanism and publish an RFC with "no
action from 3GPP". However, until 3GPP updates and ratifies their technical
specification (TS) to state that your RFC MUST be supported on a given
reference point, an operator cannot assume multi-vendor interoperability of
your RFC on that 3GPP reference point. 

/Mark

> >> applications a given Diameter node supports. Individual applications
> >> MAY provide more refined support for overload controls."
> >>
> >
> > I'm not reading a requirement for basic vs. refined support from the
> > current REQ 2 text.  I understand that REQ 2 is trying to establish
> > the bounds of acceptable impacts on existing Diameter applications.
> > IMHO it should read something like "the addition of the Diameter
> > overload control mechanism to an existing Diameter application MUST
> > NOT require the allocation of a new application id". Do we need to
> constrain the solution any further?
> >
> > I don't understand the motivation for requiring that it "MUST NOT
> > require specification changes for existing Diameter applications". If
> > 3GPP decides that Diameter overload control must be supported on an
> > existing reference point, I would expect the 3GPP TS for that release
> > to be updated to state just that. This is a "specification change" and
> > I don't see how else a vendor would know that they had to update their
> > implementation. What am I missing here?
> >
> > /Mark
> >
> >>> encourage the WG to sort out the language in REQ 2 asap. As long as
> >>> it is in flux the document cannot proceed to WGLC.
> >>>
> >>> - jouni
> >>>
> >> ...

---

From: Ben Campbell <[email-masked]>
Date: Wed, 19 Dec 2012 15:27:18 -0600

> derive the new requirement from reading revision -02.

Basically, yes. The extensibility requirement was intended, but not well documented. It's mentioned in the motivating text, but not so much in the requirements. That's why I think we should make it explicit in Req2.

> your RFC on that 3GPP reference point. 

Customers often create MUSTs that don't show up in the standards :-) That is, there may well be market pressure to implement OC whether or not the 3GPP normatively requires it. The real issue there is what happens when some vendors implement it and some don't. Req 16 talks about that. 

So far, all the proposed mechanisms require negotiation of support, so there's no interop problem introduced. That is, if one peer supports it and the other doesn't, nothing should break, although you won't get the benefit of the mechanism. I don't think we have an explicit requirement for negotiation, but I think it's pretty clearly implied by Reqs 6 and 16.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 19 Dec 2012 15:37:58 -0600

Hi Laurent, comments inline:

> I think we are approaching towards the conclusion but would like to suggest following new requirements

I hope you are right :-)

> REQ X:   A common default algorithm to react to an overload status SHOULD be defined in order to allow a basic inter-operable inter Service Provider overload mechanism.

Do you consider an algorithm for inter-service-provider OC as necessarily different from a general algorithm? 

> REQ Y:   Even though there are Diameter Agents between 2 Diameter end-points (client/server) that support the (overload control) feature, there MUST be a way to report an *overload* status to the D…

I assume from the elaboration below that this includes the case where the agents do not directly support OC?

> ·         a "MUST" instead of a "SHOULD"

I don't think I object to a MUST (pending conversation on the other parts)

> ·         the fact that even when the DA supports the mechanism the end point may need to know an *overload* status (this may be different for a *load* status)

Req 35 already says "overload and load information". Are you looking for more than that?

> ·         and (minor remark) the indication that the reaction to an overload status may imply possible non Diameter actions.

Can you elaborate on what you mean by "non Diameter actions"? I think it likely that many overload conditions will require clients to take action in whatever application protocol they provide. Nothing really uses Diameter for it's on sake (we've got a fair amount of text on that in the introductory sections). But it seems to me the specifics of such actions belong to those protocols, not this one. Do you expect that the overload information would some how explicitly signal what non-Diameter actions a client might need to take?

---

From: "Mark Jones" <[email-masked]>
Date: Wed, 19 Dec 2012 16:58:48 -0500

Hi Ben, Tom,

That explanatory text helps a lot. I still think REQ 2 should be split into
two requirements though. 

I could not find a definition of "default overload control" in the draft. In
the context of REQ 2, I interpret it as the overload control mechanism
without any application-specific extensions. If I'm right then I think it is
safe to replace it with "the overload control mechanism". If I'm wrong,
"default overload control" needs to be defined.

Could you clarify the difference between the extensibility required by REQ 2
and that required by REQ 34? I assumed the extensibility in REQ 34 was
'application-neutral' but I'd like to confirm.

/Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ben Campbell
> Sent: December-19-12 3:16 PM
> To: Tom Taylor
> Cc: [email-masked]
> Subject: Re: [Dime] New Version Notification for draft-ietf-dime-overload-
> reqs-02.txt
> 
> WFM
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 19 Dec 2012 16:03:35 -0600

> "default overload control" needs to be defined.

You are correct, and we can probably just say "the overload control mechanism"
> 'application-neutral' but I'd like to confirm.

Now that you point it out, I think 34 covers most of what I was trying to say about extensibility. I don't think anything in 34 prevents application-specific extensions. (nor does it prevent application-independent ones).