Microsoft Technology Licensing, LLC

Alexander Malysh

Omar Cardona

David G Thaler

Andrew J Ritz

Srinivas Raghu Gatta

Dmitry A Anipko

Kamalavasan Srinivasan

Alireza Dabagh

Maxim V Stepin

Deepak Bansal

Eran Yariv

Murari Sridharan

Harish Srinivasan

Robert C Combs

Narasimhan Agrahara Venkataramaiah

Narasimha Rao S S Nagampalli

Madhan Sivakumar

Gregory M Cusanza

Ronen Barenboim

Thomas Edward Molenhouse

Kamran Reypour

Satish Goswami

Chenyan Liu

Tom Xanthos

Sze K Li

Techniques for aggregating execution metrics during virtualization are provided. In some embodiments, aggregated execution metrics (e.g., average execution time) are generated and stored for different types of supported virtualization service operations executed by a virtualization service provider (VSP) in a virtualization stack handling requests from a virtualization service client (VSC) running in a computer system emulator. For example, execution calls to the VSP are intercepted, and execution metrics for a triggered virtualization service operation are generated and aggregated into an aggregation entry that represents aggregated performance (e.g., average execution time) of all instances of the virtualization service operation that were completed during an interval (e.g., 1 hour). Aggregated execution metrics may be stored for any number of historical intervals. Since aggregated execution metrics are effectively compressed, diagnostic information about a variety of different types of virtualization service operations may be stored and used to diagnose and repair underperforming components.

Generating, aggregating, and querying virtualization service execution metrics for cloud diagnostics at scale

A packet monitoring application instantiated on a server hosting a virtualized network stack is utilized to track data packet propagations and drops at each component within the network stack to reduce the amount of time to identify a root cause for latency issues. The packet monitoring application can be selectively enabled or disabled by an administrator. Components within the virtualized network stack report packet drops and successful packet propagations to the packet monitoring application, which can filter the packets based on input parameters. Thus, a user can select at what level of granularity to filter packets within the virtualized network stack while being able to assess each packet's traversal through each component within the network stack. The packet monitoring application can also perform post-processing of on the filtered data packets to determine latency among components or sections of the virtualized network stack.

Packet drop detection in local networking stack through packet correlation

A method of communicating data traffic including data packets through a virtual switch on a host device is provided. The data traffic flowing through the virtual switch is monitored. The data traffic includes at least virtual machine data traffic flowing to and from virtual machine processes on the host device and host data traffic flowing to and from host operating system processes on the host device. Each of the data packets are designated as virtual machine data traffic or host data traffic based on an evaluation of the Media Access Controller (MAC) address of each of the one or more data packets of the monitored data traffic. Virtual machine data traffic is directed through a packet processor as the virtual machine data traffic traverses the virtual switch. Host data traffic is directed to bypass the packet processor as the host data traffic traverses the virtual switch.

Virtual switch bypass

Various innovations for servicing of a virtual switch in a virtual networking layer are presented. The innovations include new architectures for a virtual networking layer and new operations performed when servicing a virtual switch. In some example implementations, during virtual switch servicing, interruption to actual network connectivity is minimal&#x2014;below a timeout threshold that signifies failure of a network connection. Connections for a host, VMs, and physical network adapter can be maintained while the virtual switch is serviced. Although some interruption to actual network connectivity happens, apparent connectivity (for a VM) over a connection between the VM and the virtual switch can be maintained during the servicing of the virtual switch. Similarly, apparent connectivity (for a host) over a connection between the host and the virtual switch can be maintained during the servicing of the virtual switch.

Maintaining apparent connectivity during virtual switch servicing

Operating system management of network interface devices is described. In one or more implementations, a determination is made by an operating system that network traffic associated with one or more applications of the computing device has completed. Responsive to the determination, a network interface device is caused to transition to a mode to reduce power consumption of the network interface device by the operating system.

Operating system management of network interface devices

A computing device that has a network interface that performs a subset of possible networking functions while the computing device is in a sleep mode. The subset of functions may be simply implemented on the network interface, yet to substantially reduce the frequency with which the computing device has to wake up to perform networking functions. The subset of functions may be selected to maintain a network presence of the computing device while the device is in sleep mode, and may include responding to requests for MAC information, sending keep-alive messages or exchanging security information that, in accordance with network protocols, has a limited lifetime that would otherwise expire while the computing device is in sleep mode.

Network presence offloads to network interface

Discovery of intermediate network devices is performed using a technique that piggybacks upon the existing standard TCP (Transport Control Protocol) 'SACK' (Selective Acknowledgment) option in a SYN/ACK packet so that discovery information may be shared between pair-wise-deployed peer intermediate devices when a TCP/IP connection (Transport Control Protocol/Internet Protocol) is first established between network endpoints using a conventional three-way handshake. Use of the SACK option is combined with another technique which comprises modifying the original 16-bit value of the TCP receive window size to a special arbitrary value to mark a SYN packet as being generated by a first peer device. The marked SYN when received by the second peer device triggers that device's discovery information to be piggybacked in the SACK option of the SYN/ACK packet. The first device then piggybacks its discovery information in the SACK option of the ACK packet which completes the three-way handshake.

Transparent auto-discovery of network devices logically located between a client and server

Aspects of the subject matter described herein relate to locally terminating an established connection. In aspects, a connection between two nodes is established. A network device lies on the path over which packets associated with the connection travel to get to either of the two nodes. After the connection is established, the network device attempts to create a safe point at which the connection can be terminated at the network device. To do so, the network device begins buffering packets and looking for information that indicates that all outstanding packets between the two nodes have been received either by one of the two nodes or have been buffered by the network device. After a safe point is reached, the network device may terminate the connection locally in a way that is transparent to the two nodes.

Locally terminating an established connection

Growing community of inventors

Bothell, WA, United States of America

Alexander Malysh