Subject: [Dime] Overload Req 2

From: Ben Campbell <[email-masked]>
Date: Mon, 7 Jan 2013 16:29:48 -0600

Hi,

We had a thread on Req 2 from the overload requirements draft that sort of trailed off over the weekend. I'd like to bring that to a conclusion soon so we can submit a version with no known open issues.

Here's proposed language (A complete replacement for Req 2)  based on that thread:

Old:

[Open Issue: The following requirement has generated list discussion that is unresolved at the time of this writing. The discussion concerns whether this requirement is needed at all, whether it should include the "MUST NOT require specification changes" language vs saying that it should not force changes large enough to require new application IDs, and whether we should include additional language to forbid assumptions about the behavior of specific implementations.] The overload control mechanism MUST be useable with any existing or future Diameter application. It MUST NOT require specification changes for existing Diameter applications.

New:

The mechanism MUST allow Diameter nodes to support overload control regardless of which Diameter applications they support. 

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.

Thanks!

Ben.