Abstract: A congested network link is identified. Applications that are contributing to the congestion are also identified. The contribution of each of the identified applications to the congestion is then determined in order to determine whether the application's usage of the network should be throttled. A control signal is generated in order to indicate to the application that it is to perform an application-specific throttling operation to reduce the network bandwidth consumed by the application. If the application-specific throttling does not sufficiently reduce network congestion, a more aggressive throttling operation is performed.

Abstract: A congested network link is identified. Applications that are contributing to the congestion are also identified. The contribution of each of the identified applications to the congestion is then determined in order to determine whether the application's usage of the network should be throttled. A control signal is generated in order to indicate to the application that it is to perform an application-specific throttling operation to reduce the network bandwidth consumed by the application. If the application-specific throttling does not sufficiently reduce network congestion, a more aggressive throttling operation is performed.

Abstract: The present application describes a detect, alert and recovery system for various cloud-based and/or network-based services. The detect, alert and recovery system receives network performance data associated with a particular namespace from various network information sources. The network performance data may be aggregated based on various scopes. The aggregated data is then analyzed to determine whether an anomaly exists. If an anomaly exists, the detect, alert and recovery system may cause the performance of various actions in order to address the anomaly.

Abstract: The present application describes a detect, alert and recovery system for various cloud-based and/or network-based services. The detect, alert and recovery system receives network performance data associated with a particular namespace from various network information sources. The network performance data may be aggregated based on various scopes. The aggregated data is then analyzed to determine whether an anomaly exists. If an anomaly exists, the detect, alert and recovery system may cause the performance of various actions in order to address the anomaly.

Abstract: A method for directing network traffic includes, at a network device, receiving network traffic provided by one or more client computing devices. The network device directs the network traffic to a service entity over a first network path. A path quality indicator is received that indicates whether the network traffic directed over the first network path satisfies one or more experience criteria. Based at least on the path quality indicator indicating that the network traffic directed over the first network path does not satisfy the one or more experience criteria, the network device redirects some or all of the network traffic to the service entity over a second network path.

Abstract: A method for directing network traffic includes, at a network device, receiving network traffic provided by one or more client computing devices. The network device directs the network traffic to a service entity over a first network path. A path quality indicator is received that indicates whether the network traffic directed over the first network path satisfies one or more experience criteria. Based at least on the path quality indicator indicating that the network traffic directed over the first network path does not satisfy the one or more experience criteria, the network device redirects some or all of the network traffic to the service entity over a second network path.

Abstract: Latency information is collected for each message as it moves through an organization. The latency information includes latency information for components processing the message. When the message is routed to the next server within the organization, the collected latency information for the server sending the message is included with the message. The collected latency information is written to a message tracking log when it either is delivered within the organization or when the message leaves the organization. The message tracking log may then be viewed such that the collected latency information may be viewed and analyzed.

Abstract: Latency information is collected for each message as it moves through an organization. The latency information includes latency information for components processing the message. When the message is routed to the next server within the organization, the collected latency information for the server sending the message is included with the message. The collected latency information is written to a message tracking log when it either is delivered within the organization or when the message leaves the organization. The message tracking log may then be viewed such that the collected latency information may be viewed and analyzed.

Abstract: Latency information is collected for each message as it moves through an organization. The latency information includes latency information for components processing the message. When the message is routed to the next server within the organization, the collected latency information for the server sending the message is included with the message. The collected latency information is written to a message tracking log when it either is delivered within the organization or when the message leaves the organization. The message tracking log may then be viewed such that the collected latency information may be viewed and analyzed.

Abstract: A root cause for a failed attempted delivery of a message is attempted to be determined before sending a non-delivery report (NDR) for the failed message. When a message fails without a known cause, the root cause is determined using the context of the message. For a given context, the root cause may be determined by a single failure or it may be determined by the relative number of failed messages delivery are deferred from being delivered, as is generation of the corresponding same context. While determining the root cause of the problem, any messages failing NDR(s), to allow time for corrective action to occur. If the problem is resolved within a predetermined time period, the deferred messages are delivered without having to issue NDR(s).

Abstract: A root cause for a failed attempted delivery of a message is attempted to be determined before sending a non-delivery report (NDR) for the failed message. When a message fails without a known cause, the root cause is determined using the context of the message. For a given context, the root cause may be determined by a single failure or it may be determined by the relative number of failed messages of same context. While determining the root cause of the problem, any messages failing delivery are deferred from being delivered, as is generation of the corresponding NDR(s), to allow time for corrective action to occur. If the problem is resolved within a predetermined time period, the deferred messages are delivered without having to issue NDR(s).

Abstract: User-defined agents and connectors are defined to process messages for a messaging application. The user-defined agents are configured to extend the capabilities of the messaging application. Each user-defined agent is associated with a connector that is configured to route messages for a particular address space according to the specified protocol. Upon receipt of a routed message within the particular address space, the messaging application on the server invokes the associated user-defined agent to process the message. The user-defined agent utilizes an API that is associated with the messaging application to assist in processing the message.

Abstract: Latency information is collected for each message as it moves through an organization. The latency information includes latency information for components processing the message. When the message is routed to the next server within the organization, the collected latency information for the server sending the message is included with the message. The collected latency information is written to a message tracking log when it either is delivered within the organization or when the message leaves the organization. The message tracking log may then be viewed such that the collected latency information may be viewed and analyzed.