2.6.15.8 Remote Busy Congestion

The intent of this feature is to provide remedial measures if it is determined that a connection to a DSR peer node is unable to process messages as fast as they are sent to it on a given DSR connection to the peer node. A connection is considered congested (BUSY) if an Answer message containing ‘DIAMETER_TOO_BUSY’ result code is received on the connection and was originated by the peer node.

Remote BUSY Congestion is determined by analyzing Diameter Answer from a connected peer. The result code ‘DIAMETER TOO BUSY’ in a Diameter Answer from a connected peer indicates the connection is congested or BUSY.

When this feature is configured, DSR sets the status of a connection to ‘BUSY’ in the following conditions:

• The result code of Diameter Answer is ‘DIAMETER TOO BUSY’.
• Origin-Host of the Answer messages is same as the connection’s Peer FQDN.

The DSR sets the status ‘BUSY’ only to the connection of a peer on which ‘DIAMETER TOO BUSY’ is received. The other connections between the DSR and the peer may or may not be BUSY.

Typically, if a connection is BUSY, it is not selected for routing of Diameter Request messages. However, based on the configuration, this behavior may be overridden and a BUSY connection may be selected to route the Request when the message is addressed to the connection’s peer FQDN.

A BUSY connection becomes uncongested after a certain minimum time has elapsed in ‘BUSY’ state. DSR provides a configurable timer to set this value.

Note:

Diameter Protocol does not provide any mechanism for a node to signal to its peers that its busy condition has abated.

The figure below shows the message flow diagram for determination of congestion in a normal case.

• DSR receives a Diameter Request Message.
• DSR selects a connection and forwards it to a connected peer (Server).
• The peer replies with ‘DIAMETER_TOO_BUSY’ result code in the Answer.
• DSR sets the Connection Status to ‘BUSY’ and starts ‘Connection Busy Abatement Timer’.
• DSR forward the DIAMETER_TOO_BUSY to client.

If ‘Reroute on Answer’ feature is configured, the DSR may attempt to perform alternate routing of Request based on DSR routing configuration.

Figure 2-24 Connection Busy

Request Priority for which a remote busy was received	Associated Connection Congestion Level	Message Priorities Allowed when support for 5 message priorities is enabled	Messages Priorities Not Allowed when support for 4 message priorities is enabled	Comment
2	CL-3	3	0,1,2	Only allow Answers to be sent on connection.
1	CL-2	3,2	0,1	Only allow Answers and Priority=2 Requests to be sent on connection.
0	CL-1	3,2,1	0	Only allow Answers and Priority=2, 1 Requests to be sent on connection.

Note:

When support for 16 message priorities is enabled then message priorities to be allowed in each of the Connection Congestion Level is decided based on ‘Connection Configuration Set’ MO assigned to individual diameter connection. The operator must specify a “Minimum Request Priority Allowed” attribute for each of CL1, CL2 and CPL3 in Connection Configuration Set. The “Minimum Request Priority Allowed” attribute assigned to a CL value defines the minimum Request message priority criteria for forwarding Request messages to that connection. For example, if the “Minimum Request Priority Allowed” attribute assigned to CL3 is 12, then DSR will forward Request messages to that connection with a priority of 12, 13, 14 or 15.

When the abatement timer expires, the congestion level is decremented by one thereby allowing Requests with the next lower priority and the abatement timer is restarted. For the example above, after the abatement timer expires, priority 2 and above Requests will be allowed over the connection. This process continues until the congestion level of the connection drops back to zero. This behavior is illustrated in the figure below:

Note:

Diameter Protocol does not provide any mechanism for a node to signal to its peers that its busy condition has abated.

Figure 2-25 Congestion level abatement over time for Remote Busy