Subject: [Dime] comments on REQ 18 in draft-ietf-dime-overload-reqs-02

From: jinzhu wang <[email-masked]>
Date: Mon, 7 Jan 2013 14:38:10 +0800

Dear All:

By reading the draft-ietf-dime-overload-reqs-02, I have few comments on REQ
18.

REQ 18:      In a mixed environment of nodes that support the overload

            control mechanism and that do not, users and operators of

            nodes that do not support the mechanism MUST NOT unfairly

            benefit from the mechanism.

It may be necessary to further clarify the meaning of the “unfairly
benefit” in the context of Diameter overload control. The “unfairly
benefit” may indicate achieving higher effective throughput, obtaining a
higher share of the service of upstream node, or others. Thus, a more
thorough explanation of “unfairly benefit” is needed.

In addition, since the fairness is an important performance metric of
overload control mechanism (as in SIP overload control, RFC6357 section 7),
should we need to define the fairness in Diameter overload control and
propose the requirements on fairness of overload control mechanism? For
example, the nodes that support the overload control mechanism MUST fairly
share the service of upstream node.

Best Regards

Jinzhu Wang

China Mobile

---

From: Ben Campbell <[email-masked]>
Date: Mon, 7 Jan 2013 20:31:18 -0600

Hi,

Please see inline:

Thanks!

Ben.

On Jan 7, 2013, at 12:38 AM, jinzhu wang <[email-masked]> wrote:

> Dear All:
> 
> By reading the draft-ietf-dime-overload-reqs-02, I have few comments on REQ 18.
> 
> It may be necessary to further clarify the meaning of the “unfairly benefit” in the context of Diameter overload control. The “unfairly benefit” may indicate achieving higher effective throughput, obtaining a higher share of the service of upstream node, or others. Thus, a more thorough explanation of “unfairly benefit” is needed.
> 

I don't think we intended to introduce the idea of fairness as a measurable quantity in this draft, and certainly not with the degree of precision in RFC 6357. It was a deliberately imprecise term to describe a deliberately imprecise concept. In fact, the word "unfair" was introduced in this most recent version to try to better explain the previous wording. If it can't stand without a definition, then I think we should revert back, and add some more explanation.

In particular, we are trying to avoid the scenario where a non-supporting node gains an advantage over a supporting node merely from the fact that it doesn't support the mechanism. For example, consider if an overloaded server asks clients to reduce the traffic. A supporting node does so. A non-supporting node continues to send the original traffic level, and gets more transaction completions than the supporting server. That particular example suggests that the server can't simply assume that all clients will honor the request, and still needs to implement whatever internal load-shedding mechanism it would have used without the overload control mechanism.

That's one example, and there may be others. Maybe it would help to restate this as a design consideration rather than a requirement?

> In addition, since the fairness is an important performance metric of overload control mechanism (as in SIP overload control, RFC6357 section 7), should we need to define the fairness in Diameter overload control and propose the requirements on fairness of overload control mechanism? For example, the nodes that support the overload control mechanism MUST fairly share the service of upstream node.
> 

I don't think we set out to define performance metrics in this draft. It might be good to have them, but I'm not sure they belong here. What do others think?

---

From: jinzhu wang <[email-masked]>
Date: Wed, 9 Jan 2013 11:31:46 +0800

Hi Ben,
Please see inline:

Best Regards

Jinzhu Wang
China Mobile

> That's one example, and there may be others. Maybe it would help to restate this as a design consideration rather than a requirement?

<J.Z.> Thanks for the thorough explanation. I agree with the
requirement of preventing the non-supporting node gaining an advantage
over a supporting node and I think it is better to give a more
explanation to this requirement instead of using the word “unfair”.

> I don't think we set out to define performance metrics in this draft. It might be good to have them, but I'm not sure they belong here. What do others think?

<J.Z.> The main performance metrics of the overload control mechanism
consist of throughput, responsiveness, fairness, etc. I notice that
the requirements of high throughput and high responsiveness have
already been proposed. (REQ 3 requires high throughput and REQ 14
requires high responsiveness). In this regard, the requirement of good
fairness may be needed?