Subject: [Dime] draft-ietf-dime-overload-reqs-03: some REQ comments and questions

From: Andrew Booth <[email-masked]>
Date: Tue, 5 Feb 2013 00:13:20 -0500

Some minor questions and comments on various requirements.

REQ 7: I'm not sure that "the system remains stable" adds much on its own, removing it doesn't seem to lose much:

ALT REQ 7: The overload control mechanism and any associated

default algorithm(s) MUST ensure that when the

offered load drops from above the overall

capacity of the network to below the overall

capacity, the throughput MUST stabilize and become

equal to the offered load.  Note that this also

requires that the mechanism MUST allow nodes to

shed load without introducing oscillations.

REQ 7: query: Does this requirement imply that the proposed mechanism must define one or more options for shedding load (as opposed to simply requesting the clients to slow down)?  Is it accurate to say that processing TLS to get at the Diameter message may be a substantial part of the message processing time, so a node may have limited ability to distinguish between Diameter messages when shedding load?  This query applies to REQ 22 also.

REQ 9: Is this simpler/clearer?  Or did I miss some cross references?

ALT REQ 9:   The mechanism MUST function across fully loaded as well as

quiescent transport connections.  This is partially derived

from REQ 7 above.

REQ 13: consider adding "The mechanism SHOULD NOT introduce substantial additional work for nodes that are not in overload; in particular it should not cause nodes to become overloaded".

REQ 20: does "actual overload" deserve more clarification?  For example, would any or all of the following would represent "actual overload": CPU usage, a deep send queue, messages incoming at an unexpectedly high rate?  Or is this something that would be defined by the proposed mechanism?  Or have I misunderstood completely?

REQ 21: Does this imply that a node must be able to deduce overload of a peer or indirectly accessible node based on local metrics only (response time, send queue depth, etc)?  Since "The mechanism MUST properly function in these cases", does that require that explicit messaging is unnecessary?

REQ 29: query: why do we need to know who sent the overload info (note that the security concerns are addressed in other requirements)?  Do we lose anything by removing the first sentence?

ALT REQ 29:  The mechanism MUST allow a node to distinguish between

overload at a next-hop peer from overload at a node upstream

of the peer.  For example, in Figure 5, the client must not

mistake overload at server 1 for overload at the agent,

whether or not the agent supports the mechanism.

REQ 29: nit: why the cross reference to REQ 4?

REQ 33: "The mechanism MUST allow Diameter nodes to indicate overload with sufficient granularity to allow clients to take action based on the overloaded resources without forcing available capacity to go unused.": this wording seems to imply that the mechanism must support overload specification of arbitrary granularity, with a corresponding increase in the complexity required on implementations.  Even supporting "Diameter session" could force a node to maintain session state when it is otherwise not required (more an issue for Agents than end nodes), at a corresponding increase in the cost and complexity of that node.  Is there anything to be concerned about here?  Or is REQ 13 sufficient to limit complexity?

REQ 35: query: explicitly mention that end-to-end security is required here?  Or is it not?

REQ 35: query: does this pretty much rule out strictly a hop-by-hop approach?

Thanks,

Andrew

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 5 Feb 2013 08:29:14 +0200

> REQ 35: query: explicitly mention that end-to-end security is required here?  Or is it not?

Since we have no standardized e2e security mechanism in Diameter at the moment that would allow intermediates to see the Diameter traffic, we cannot really require it. The discussion in security considerations should cover this part. We could point at the discussion in the security considerations though.

> REQ 35: query: does this pretty much rule out strictly a hop-by-hop approach?

Hm.. it says SHOULD, not MUST. So if you have a good reason your solution can be such that it cannot bypass non-supporting intermediates.

- JOuni

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

---

From: Andrew Booth <[email-masked]>
Date: Tue, 5 Feb 2013 14:06:04 -0500

Hi Jouni,

Ok, that works for me.

Thanks,
Andrew

-----Jouni Korhonen <[email-masked]> wrote: -----
To: Andrew Booth <[email-masked]>
From: Jouni Korhonen <[email-masked]>
Date: 02/05/2013 01:29AM
Cc: [email-masked]
Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: some REQ comments and questions

- JOuni

---

From: Eric McMurry <[email-masked]>
Date: Sat, 16 Feb 2013 10:29:06 -0600

Hi Andrew,

Sorry for the delay.  Please see inline.

Thanks,

Eric

>                shed load without introducing oscillations.

The text after the first sentence was intended to elaborate on it.  It would probably read about the same either way, but I don't think it detracts having it there.

> REQ 7: query: Does this requirement imply that the proposed mechanism must define one or more options for shedding load (as opposed to simply requesting the clients to slow down)?  Is it accurate t…

I don't think this requirement implies that there be multiple algorithms, but that is called out elsewhere (at least the ability to add them).

Impact of TLS is rather implementation dependent.  I'm not sure what we could say about that here (or that we should)

>                quiescent transport connections.  This is partially derived

makes sense.  good catch.

> REQ 13: consider adding "The mechanism SHOULD NOT introduce substantial additional work for nodes that are not in overload; in particular it should not cause nodes to become overloaded".

not causing other nodes to be come overloaded is covered in req 12 and 23.  No introducing substantial work when not overloaded is probably a subset of what is there.  I think that was in an earlier version of the draft and was considered redundant.  Perhaps others remember that better.

> REQ 20: does "actual overload" deserve more clarification?  For example, would any or all of the following would represent "actual overload": CPU usage, a deep send queue, messages incoming at an u…

the word actual may not actually add anything here.  All of the things you mentioned could be causes of overload.  I think the intent though is that existing Diameter errors not be overloaded to be used for overload.  Any overload control mechanism needs to be clear about what is being communicated. 

> REQ 21: Does this imply that a node must be able to deduce overload of a peer or indirectly accessible node based on local metrics only (response time, send queue depth, etc)?  Since "The mechanism…

perhaps "properly function" should be stated differently.  The intent here is that the mechanism not break things in this case and that the overload is handled at least as well as it would have been were the overload control signaling intact.  The language in req 17 is close to this point I think.  How about we barrow that language?

REQ 21:  In cases where a network node fails, is so overloaded that
            it cannot process messages, or cannot communicate due to a
            network failure, it may not be able to provide explicit
            indications of the nature of the failure or its levels of
            congestion.  The mechanism MUST result
            in at least as much useful throughput as would have resulted
            if the overload control signaling were present.

This may imply the actions you mention, as so other requirements around functioning in environments with nodes that do, and do not support the mechanism, and fairness in that case.  Overload can be mitigated somewhat without overload control signaling, but that is not sufficient to handle issues that are occurring on networks now.  A good bit of the front matter in the draft discusses this point.

> REQ 29: nit: why the cross reference to REQ 4?

I agree with this and would go further.  Upon reading this again, I don't think req 29 is adding anything.  Perhaps we should just add this example to 33 and remove 29.

> REQ 33: "The mechanism MUST allow Diameter nodes to indicate overload with sufficient granularity to allow clients to take action based on the overloaded resources without forcing available capacit…

I think req 13 probably covers this.  I understand your concern though, and share it.  There is potential for significant complexity.  There have been a lot of comments on this point and I think there will be a fair amount of thinking going into appropriate scoping of overload control information in ways that balance work imposed on nodes with capacity left on the table. Perhaps adding the word "unreasonably" in between "without" and "forcing" would make folks feel more comfortable that the necessary wiggle room is here for the mechanism specifiers.

> REQ 35: query: does this pretty much rule out strictly a hop-by-hop approach?

Jouni answered these last two and that looked reasonable to me.