Microsoft Technology Licensing, LLC

Todd Carlyle Luttinen

Victor Boctor

Wilbert De Graaf

Gregory Gourevitch

Jeffrey B Kay

Bradley David Rutkowski

Gregory Irving Thiel

Rajesh Kumar Maskara

Lizhuang Zhao

Kushal Suresh Narkhede

Jesse M Dougherty

Saraswathy Srinivasan

Malcom Pearson

Timothy Mark Moore

David Foster Mills

Joseph Warren

Mathrubootham Janakiraman

Konstantin E Ryvkin

Sara L Manning

Srinivasachakrapani Kotipalli

Victor W H Boctor

Saurabh Vats

Irina Andreea Rosoiu

Malvika Modi

Fangwen Yu

Liting Zhao

Zhenguo Yang

Xuelin Chen

Sachin Ramakanth Kulkarni

Vijay Rajesh Kumar

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.

Controlling network throughput using application-level throttling

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.

Triggering recovery actions based on corroborating anomalies

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.

Network path redirection

Various embodiments of the present technology generally relate to systems and methods for intelligent load shedding. More specifically, various embodiments of the present technology generally relate to intelligent load shedding of traffic based on current load state of target capacity. In some embodiments, a first server can send a capacity request indicating that the first server is nearing capacity and needs assistance with load. In response to the capacity request, an assistance request can be published to additional nearby servers. The servers can respond with a status update providing load and availability information. Based on the load and availability information (or other information such as latency), a second server from the additional servers can be selected and traffic can be routed away from the first server to the second server.

Near real-time computation of scaling unit's load and availability state

Various embodiments of the present technology generally relate to systems and methods for intelligent load shedding. More specifically, various embodiments of the present technology generally relate to intelligent load shedding of traffic based on current load state of target capacity. In some embodiments, a domain name resolution request to translate a domain name into an Internet protocol (IP) address can be received at DNS server. A status of each of multiple scaling units mapped to the domain name can be determined. A set of IP addresses (e.g., four IP addresses) corresponding to a subset of the multiple scaling units closest to the requesting device with statuses indicating availability for new traffic can be identified. Then, the set of IP addresses can be sent to the requesting device. The requesting device can the select which IP address to use (e.g., randomly) to route the traffic.

Intelligent load shedding of traffic based on current load state of target capacity

Message prioritization may be provided. First, a message may be received and a priority level may be calculated for the message. If the message is not rejected for having a priority lower than a predetermined threshold, the message may be placed in a first priority queue. Next, the message may be de-queued from the first priority queue based upon the calculated priority level for the message. Distribution group recipients corresponding to the message may then be expanded and the priority level for the message may be re-calculated based upon the expanded distribution group recipients. Next, the message may be placed in a second priority queue. The message may then be de-queued from the second priority queue based upon the re-calculated priority level for the message and delivered.

Using e-mail message characteristics for prioritization

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.

Detailed end-to-end latency tracking of messages

Architecture for efficiently ensuring that data is stored to the desired destination datastore such as for replication processes. A copy of data (e.g., messages) sent to a datastore for storage is stored at an alternate location until a received signal indicates that the storage and replication was successful. As soon as the feedback signal is received, the copy is removed from the alternate location, and hence, improves input/output (I/O) and storage patterns. The feedback mechanism can also be used for monitoring the status of data transport associated with log shipping, for example, and taking the appropriate actions when storage (e.g., replication) is not being performed properly.

Data replication feedback for transport input/output

Architecture that facilitates transport high availability for messaging services by providing the ability of a receiving entity (e.g., receiving message transfer agent (MTA)) to detect if a sending entity (e.g., sending MTA or client) is a legacy sending entity. When the receiving entity detects that the sending entity is a legacy system, by advertising transport high availability capability to the sending entity, if the sending entity does not opt-in to this capability, the receiving entity keeps the sending entity client 'on hold', that is, waiting for an acknowledgement (ACK) until the receiving entity delivers the message to the next hops (immediate destinations). This approach maintains at least two copies of the message until the message is successfully delivered (to the next hop(s)). Hence, if the legacy sending entity or the receiving entity fails, the message is still delivered successfully.

Transport high availability via acknowledge management

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).

Throttling non-delivery reports based on root cause

A system provides high availability electronic message forwarding. When an electronic message is communicated to a first server, a copy of the electronic message is maintained at a second server. The electronic message is maintained on both servers until the electronic message is successfully communicated to a third server. After the message is delivered to the third server, the electronic message is removed from both the first server and the second server. If the first server fails to communicate the electronic message to the third server, the second server does so.

Growing community of inventors

Redmond, WA, United States of America

Todd Carlyle Luttinen