Patent Description:
<CIT> relates to flow monitoring in a virtual datacenter. A target flow pattern describing data packets of interest is distributed to a plurality of applications managing VMs in the virtual datacenter, such as hosts, virtual gateways, and other virtual network applications. Each of the applications monitors data packets routed by the application by comparing the data packets to the flow pattern and selectively collecting context data describing the data packets. The context data collected by the applications is aggregated at a remote server for analysis and reporting.

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 a computer server administrator. When disabled, the components within the virtualized network stack do not report packet propagations or drops to the packet monitoring application. When enabled, the components call the application programming interface (API) associated with the packet monitoring application and report packet drops and propagations to the packet monitoring application. A user can input parameters into the packet monitoring application by which certain packets are selected for exposure to the user and other packets are ignored or disregarded. Filtration parameters can include a customized level of granularity in the virtualized network stack components, including a monitoring level within the components (e.g., miniports or specific components within the virtualized network stack), and communication protocol (e.g., Transmission Control Protocol (TCP), User Datagram Protocol (UDP), etc.), among other parameters. Unique correlation identifiers (IDs) are associated with each data packet to enable tracking of packets across each component in the network stack. The ability to identify packet propagation and drops at each component within the network stack enables a user to identify where packet drops or latency occurs within the network stack, and thereby reduce the time to identify a root cause. Post-processing of the filtered data packets can also be implemented in which various determinations or calculations are performed on the data packets, such as packet latency at the entire or a portion of the network stack, packet propagation averages through components in the network stack, etc..

It will be appreciated that the above-described subject matter may be implemented as a computer-controlled apparatus, a computer process, a computing system, or as an article of manufacture such as one or more computer-readable storage media. These and various other features will be apparent from a reading of the following Detailed Description and a review of the associated drawings.

Like reference numerals indicate like elements in the drawings. Elements are not drawn to scale unless otherwise indicated.

<FIG> shows an illustrative environment in which customer computing devices <NUM> communicate data packets <NUM> over network <NUM> with computer servers <NUM> that may be operating in a datacenter. The network may include a local area network, wide area network, and the internet. A computing device <NUM> local to the computer servers may be configured with a user interface to enable a user <NUM> to control aspects and operations over the computer servers. The computer servers in the datacenter may be associated with a cloud service provider that provides solutions to customers operating the customer computing devices. The computer servers may, for example, host virtual machines or containers which are each associated with and accessible by a unique customer. The virtual machines and containers may provide solutions to the customer computing devices such as data analytics, data storage, artificial intelligence processes, etc. A single computer server can host many virtual machines and/or containers which are respectively accessible by multiple different customers.

The customer computing devices <NUM> can be any number of devices which are configured with network connectivity to connect with and leverage the solutions offered by the computer servers <NUM>. Non-exhaustive types of computing devices include a laptop computer, smartphone, tablet computer, a local server, and Internet of Things (IoT) devices which can collect and report telemetry data (as generically and illustratively shown by the System on a Chip (SoC) device). Multiple data packets <NUM> can be transmitted between the computer servers and the customer computing devices.

<FIG> shows an illustrative diagram of a virtualized networking stack <NUM> configuration for a host computer server. Each component within the networking stack may communicate with a packet monitor application programming interface (API) <NUM>. For example, each stack component may perform an API call <NUM> and report packets <NUM> to the packet monitoring application <NUM>, such as a status of a packet (e.g., packet drops and successful packet propagations). The packets <NUM> may go in either direction, that is, delivery or reception, within the network stack. The virtualized network stack may be utilized to deliver packets to a respective customer's virtual machine or container. Thus, multiple virtual machines and containers operated by multiple different customers can operate within a datacenter and be processed together by a single computer server or multiple computer servers.

A brief description of the components within the virtualized network stack <NUM> follows. While some of the monikers utilized throughout the description and drawings may be specific to the Windows® platform, the described functionality may be applicable to any implementation. In other implementations of the virtualized network stack, for example, some of the components depicted may not be employed or additional components may be employed.

The networking application <NUM> may be utilized to provide to a user control over the components. The packet monitoring application <NUM> is exposed to the user on a user interface associated with the computer server for enabling or disabling invocation of the packet monitor API <NUM> by the components within the network stack.

The network interface controller (NIC) <NUM> may be the hardware device implemented to enable Wi-Fi, ethernet, or other connections. The NIC <NUM> may provide the physical and data link layer network communications to another device, such as a router. The NDIS (Network Driver Interface Specification) <NUM> provides an API for the NIC which includes a library of functions which serves as a standard interface. The WFP (Windows® Filtering Platform) (i.e., WFP MAC <NUM>) is a set of system services and an API that provides a platform for creating network filtering applications. The WFP allows developers to write code that interacts with the packet processing that takes place at several layers in the networking stack of the operating system. For example, developers can implement firewalls, intrusion detection systems, antivirus programs, network monitoring tools, and parental controls, etc., all before the data reaches its destination. In this example, the WFP filtering may apply at the MAC address level or the IP address level (see WFP IP <NUM>).

The virtual filtering platform (VFP) <NUM> is an extension for a virtual switch (vSwitch) <NUM> for the virtual network stack which enables core software defined networking (SDN) functionality for networking services. The VFP may be a programmable network component that exposes an easy-to-program abstract interface to network agents that act on behalf of network controllers like a virtual network controller and software load balancer controller. By leveraging host components and performing packet processing on a host computer server running in the datacenter, the SDN data plane increases scalability for delivery and reception of data.

Pacer <NUM> is an abbreviated term for Packet Scheduler which is a filter intermediate driver that is provided and enforces quality of service (QoS) parameters for network data flows. The pacer may perform a variety of functions to ensure QoS, including allowing an administrator to prioritize network traffic and limit bandwidth utilization so that the operating system continues to perform certain operations, among other functions.

The TCP/IP (Transmission Control Protocol / Internet Protocol) <NUM> is the communication protocol utilized at a transport layer and network layers of the TCP/IP stack. These layers establish a reliable connection between a host and client device (e.g., the computer server and the customer computing devices) and route packets between networks. The WinNAT (Windows® Network Address Translation) <NUM> is utilized to translate private IP addresses assigned to a virtual service (e.g., virtual machine, container, or other service) operating on the computer server and share the public IP address which is routable to the internet. The WFP IP <NUM> is utilized as described above with respect to WFP MAC <NUM>.

Winsock <NUM> is an API that handles input/output requests for internet applications within an operating system. Winsock may operate between an application (e.g., a web browser) and the TCP/IP layer, and provides an interface for different versions of operating systems. The AFD (Ancillary Function Driver) <NUM> is a kernel driver that may be utilized with Winsock to enable the computer server to communicate with hardware or connected devices. WSK (Winsock Kernel) <NUM> is a kernel-mode network programming interface (NPI) which creates a network interface between network modules that can be attached to one another. For example, client modules registered as a client to a particular NPI can be attached to provider modules that are registered as providers of the same NPI.

HTTP (HyperText Transfer Protocol) <NUM> and SMB (Sever Message Block) <NUM> protocol are exemplary communication protocols that operate at the application layer of the TCP/IP model. HTTP utilizes requests and responses to communicate between a client and a server. SMB is a protocol that allows systems operating within the same network to share files. Other application layer protocols not shown can also be implemented, including SMTP (Simple Mail Transfer Protocol), and FTP (File Transfer Protocol).

The descriptions provided above with respect to <FIG> are applicable to the virtualized network stack depicted in <FIG>. For example, <FIG> depicts generic terms and functions within each network stack <NUM>. The propagation points <NUM> depict where packets transfer from one component to the next.

The filters <NUM> and extension <NUM> associated with the NDIS <NUM> may, for example, implement the functionality described above with respect to the WFP and VFP and perform filtering functions for the packets. The port NIC (ptNIC) <NUM> may be a port into or out of the vSwitch <NUM> and the extension NIC (extNIC) <NUM> may be the interface to the extension <NUM> associated with the NDIS <NUM>. The ptNIC may provide an external virtual port for connectivity to the external physical network and can provide a connection to physical functions or virtual functions. The extension protocol (extProt) <NUM> may be utilized to forward the packets to the next layer within the virtualized network stack, such as the host NIC (hNIC) <NUM> or virtual machine NIC (vmNIC) <NUM>. The vmNIC can transfer packets to or from the virtual machines or containers <NUM> and can be utilized to connect the virtual machine to the internet or to bridges to different network segments.

The hNIC <NUM> may be utilized to transfer packets to or from operations or applications on the computer server distinct from the virtual machines or containers. When a packet goes through the hNIC, the NDIS <NUM> and filters <NUM> are applied to the packets before forwarding the packet to the TCP/IP stack, which illustratively shows the transport <NUM>, network <NUM>, and framing <NUM> layers. The callouts <NUM> may be a set of functions exposed by a driver that is used for specialized filtering and manipulation of packets, such as virus scan, parental controls for inappropriate content, and packet data parsing, among other functions.

The virtual machine / containers <NUM> serve different functions and can be configured differently by customers. A virtual machine is an emulation of a computer system that is instantiated on a host computer server, in which multiple virtual machines running in isolation can be employed. Virtual machines include their own virtual hardware, including processing units, memory, network interfaces, etc. Virtual machines can run different guest operating systems and applications depending on the customer's configuration. Containers likewise can perform processes for customers but may not utilize a guest operating system as with the virtual machine, rather, containers consist of the application code to perform a function. Containers may be isolated to the application code and what is necessary to perform the container's intended function.

<FIG> shows an illustrative environment in which the user <NUM> enters input into the computing device <NUM> to enable the packet monitoring application. Upon enabling the packet monitoring application, the components <NUM> within the virtualized network stack <NUM> call the packet monitor API <NUM>. The virtualized network stack <NUM> is used to represent, for example, the network stacks depicted in <FIG> or <FIG>. Likewise, components <NUM> are used to represent any one or more of the network components, physical or virtual, of the network stacks depicted in <FIG> or <FIG>. Thus, references to the components can reference any one or more of the network components that make up the virtualized network stack, including the NDIS, vSwitch, NIC, TCP/IP, vmNIC, filters, extensions, etc..

<FIG> shows an illustrative diagram in which registered components <NUM> transmit reports <NUM> to the packet monitor API <NUM>. The reports include packet information for successful packet propagation <NUM> and packet drops <NUM> at the components. Successful packet propagation may be assessed and reported based on the boundaries (or edges) of the components, such as where the packets enter and leave the component (see, for example, propagation points <NUM> in <FIG>). Packet drops may be assessed and reported at any point within the component so that the packet monitor API has the information as to where the packet drop occurred intra-component. This information can be useful in determining whether specific functions within a component are interfering with packet propagation.

<FIG> shows an illustrative environment in which the user <NUM> uses the computing device <NUM> to input packet filtration parameters used by the packet monitoring application <NUM>. The parameters are used by the packet monitoring application in assessing which packet information to select for display on the user interface on the computing device <NUM> and which packet information to ignore or disregard. Depending on the scenario, certain packets may be more probative and related to a latency issue experienced by a customer than other types of packets. Connectivity issues experienced by a customer may indicate to an administrator of the computer server on which the virtualized network stack is located that HyperText Transfer Protocol (HTTP) packets are pertinent to identify where the latency or packet drops are occurring on the network stack. Server Message Block (SMB) or other protocols may be irrelevant to the user's browser connectivity issues, and therefore are filtered out and not presented to the user by the packet monitoring application <NUM>.

<FIG> shows an illustrative taxonomy of parameters <NUM> by which the packet monitoring application filters received packets within the virtualized network stack. The non-exhaustive parameters include monitoring level (e.g., miniports only, specific component, all components, etc.) <NUM>, media access control (MAC) source and/or destination <NUM>, ethernet protocol (e.g., any, IPv4 (Internet Protocol version <NUM>), IPv6, ICMP (Internet Control Message Protocol), ICMPv6) <NUM>, VLAN (Virtual Local Area Network) ID <NUM>, IP address source or destination (e.g., any, one address, or two addresses) <NUM>, communication protocol (e.g., any, TCP (Transmission Control Protocol), UDP (User Datagram Protocol)) <NUM>, TCP flags (e.g., TCP SYN (synchronize), TCP RST (reset), or TCP FIN (finish)) <NUM>, port source and/or destination (e.g., any, one port, or two ports) <NUM>, packet encapsulation (examine inner and/or outer packets) <NUM>, and the type of traffic (e.g., storage, web-based, artificial intelligence, etc.) <NUM>. Any one or more of these parameters can be input and configured into the packet monitoring application to filter and track particular packet configurations that are informative to a packet loss or latency issue experienced by a customer.

<FIG> shows an illustrative diagram in which the packet monitoring application <NUM> assigns <NUM> correlation identifiers (IDs) <NUM> to each packet <NUM>. The correlation IDs are unique to a particular data packet and follow that data packet throughout each component <NUM> (<FIG>) in the virtualized network stack <NUM>. The correlation ID may be, for example, a <NUM>-bit number on a <NUM>-bit operating system or a <NUM>-bit number on a <NUM>-bit operating system. Deployment of the correlation IDs enables the packet monitoring application to display the data path of the data packet, which can be informative for detecting packet latency, packet drops, etc. The user can therefore utilize parameters to filter which packets to track or disregard and then review each individual packet or group of like packets traversing through the virtualized network stack.

<FIG> shows an illustrative diagram in which the correlation ID <NUM> follows the packet <NUM> through each component <NUM> that the packet traverses. Each component may be a different network component in the virtualized network stack (e.g., a vSwitch, filter, virtual port, etc.). The packet monitoring application <NUM> (<FIG>) is configured to display to the user each component in which a single data packet traverses using its assigned correlation ID. The correlation ID is preserved for each packet through packet transformations, such as packet encapsulations, network address translations, etc. The correlation ID is associated with the original packet and therefore any transformations to the packet are identifiable so that the original packet can still be identified. That is, for example, an outside header on an inner packet is recognizable so that the inner packet can still be tracked throughout the virtualized network stack.

<FIG> shows an illustrative diagram in which the packet monitoring application <NUM> can leverage the correlation IDs <NUM> associated with respective data packets <NUM> to perform post-processing <NUM> on the filtered data packets. Post-processing tasks can include the packet monitoring application assessing scenarios in which customer issues are occurring <NUM>, determine packet latency at components <NUM>, determine a duration of time a packet takes to traverse a portion of the network stack <NUM>, and calculate averages of packet propagations across a defined portion or whole of the network stack <NUM>.

Regarding the assessment of scenarios, the packet monitoring application may trigger certain points within the virtualized network stack across one or multiple computer servers through which packets traverse. For example, in the scenario in which load balancing is performed for a customer-related issue, the packet monitoring application may be enabled on the computer server that performs the load balancing, a receiving server to which the packets are directed, and an originating server from which packets may have been transmitted to the customer's computing device. If data is not being load balanced, then the packet monitoring application may be enabled on the computer server being used. The correlation IDs can be used across computer servers to enable consistent review of a data packet throughout its traversal path. Other scenarios are also possible. Scenarios may be implemented through user input at a user interface associated with the computer server, or alternatively may be an automated process.

The components may report a timestamp for each data packet to the packet monitoring application. The timestamp may be associated with the boundaries (e.g., entrance and exit points) of components or within respective components (e.g., for packet drops). The capability to track packets traversing through the components enables the packet monitoring application to utilize the associated timestamp to perform at least some of the post-processing <NUM> operations. For example, subtracting a timestamp's value when the packet was in one component from another timestamp value in a subsequent component can provide the latency for that data packet, at least with respect to those components. This information can also be utilized to calculate traversal averages, among other calculations.

The ability to track packets with a customizable level of granularity through each component of the virtualized network stack enables a user to quickly identify a root cause of a latency issue experienced by users. This can save network bandwidth by addressing packet drops and latency issues which may otherwise be stalling packet propagation. Automated processing which can identify increased latency relative to expected latency at components or a collection of components can further expedite the root cause determination to enable users to identify and address the problem. Greater networking speeds can ultimately be realized on the computer server, virtual machines and containers operating on the computer server, and customer devices utilizing the services provided by the computer server and the datacenter.

<FIG> shows a taxonomy of information reported by components <NUM> for data packets <NUM> to the packet monitoring application <NUM>. The reported information can include a component name <NUM>, dropping functions name and line number (for drops) <NUM>, drop reason from a global ENUM (enumeration) list (for drops) <NUM>, packet payload or header information <NUM> including a payload type (e.g., ethernet name, IP frame, etc.) <NUM>, TCP / UDP ports (e.g., source and/or destination) <NUM>, packet direction (e.g., send or receive) <NUM>, user mode process name <NUM>, interface ID <NUM>, instance ID (e.g., NDIS handle) <NUM>, net buffer list (NBL) out of band (OOB) information <NUM>, ethernet header information (e.g., source, destination, protocol) <NUM>, VLAN ID <NUM>, and IP header information (e.g., source, destination, protocol) <NUM>.

<FIG> are flowcharts of illustrative methods <NUM>, <NUM>, and <NUM>, that may be performed using the computer server <NUM> or the computing device <NUM>. Unless specifically stated, the methods or steps shown in the flowcharts and described in the accompanying text are not constrained to a particular order or sequence. In addition, some of the methods or steps thereof can occur or be performed concurrently and not all the methods or steps have to be performed in a given implementation depending on the requirements of such implementation and some methods or steps may be optionally utilized.

In step <NUM>, in <FIG>, the computer server enables operation of a packet monitoring application which triggers each component in a virtualized network stack to call an API associated with the packet monitoring application. In step <NUM>, the computer server receives, at the packet monitoring application, parameters by which to filter packets. In step <NUM>, the computer server receives, at the packet monitoring application, packets from components within the virtualized network stack. In step <NUM>, the computer server filters, by the packet monitoring application, packets received from the components using the parameters. In step <NUM>, the computer server assigns, at the packet monitoring application, correlation IDs to each packet to enable correlation and tracking of packets as the packets traverse components of the virtualized network stack.

In step <NUM>, in <FIG>, the computer server communicates packets with one or more customer computing devices, in which, during communications, packets traverse through components of a virtualized network stack on the computer server. In step <NUM>, the components of the virtualized network stack report a packet's traversal status to a packet monitoring application. In step <NUM>, the computer server assigns a correlation ID to each packet. In step <NUM>, the computer server utilizes the correlation ID to track packets across the components on the virtualized network stack. In step <NUM>, the computer server configures the packet monitoring application to filter packets according to set parameters, such that respective packets are selected for display on the user interface associated with the computer server.

In step <NUM>, in <FIG>, the computer server exposes a user interface to a user to enable a packet monitoring application which causes components within a network stack to report packets to a packet monitoring application. In step <NUM>, the computer server receives a selection of one or more parameters at the user interface that details which packets to select by the packet monitoring application. In step <NUM>, the components within the network stack invoke an API associated with the packet monitoring application. In step <NUM>, the packet monitoring application receives packets from the components of the network stack. In step <NUM>, the packet monitoring application filters the received packets using parameters, in which packets that fit the parameters are selected by the packet monitoring application to be displayed on the user interface. In step <NUM>, the packet monitoring application assigns a unique correlation ID to the filtered packets, in which the correlation ID assigned to the packets follows a respective packet through the network stack. In step <NUM>, the packet monitoring application calculates latency for the packets at the components using information about packet propagations. In step <NUM>, the computer server displays a report that includes the calculated latency and the packet drops for the filtered packets.

<FIG> is a high-level block diagram of an illustrative datacenter <NUM> that provides cloud computing services or distributed computing services that may be used to implement the present packet drop detection in local networking stack through packet correlation. A plurality of servers <NUM> are managed by datacenter management controller <NUM>. Load balancer <NUM> distributes requests and computing workloads over servers <NUM> to avoid a situation wherein a single server may become overwhelmed. Load balancer <NUM> maximizes available capacity and performance of the resources in datacenter <NUM>. Routers/switches <NUM> support data traffic between servers <NUM> and between datacenter <NUM> and external resources and users (not shown) via an external network <NUM>, which may be, for example, a local area network (LAN) or the Internet.

Servers <NUM> may be standalone computing devices, and/or they may be configured as individual blades in a rack of one or more server devices. Servers <NUM> have an input/output (I/O) connector <NUM> that manages communication with other database entities. One or more host processors <NUM> on each server <NUM> run a host operating system (O/S) <NUM> that supports multiple virtual machines (VM) <NUM>. Each VM <NUM> may run its own O/S so that each VM O/S <NUM> on a server is different, or the same, or a mix of both. The VM O/S's <NUM> may be, for example, different versions of the same O/S (e.g., different VMs running different current and legacy versions of the Windows® operating system). In addition, or alternatively, the VM O/S's <NUM> may be provided by different manufacturers (e.g., some VMs running the Windows® operating system, while other VMs are running the Linux® operating system). Each VM <NUM> may also run one or more applications (Apps) <NUM>. Each server <NUM> also includes storage <NUM> (e.g., hard disk drives (HDD)) and memory <NUM> (e.g., RAM) that can be accessed and used by the host processors <NUM> and VMs <NUM> for storing software code, data, etc. In one embodiment, a VM <NUM> may employ the data plane APIs as disclosed herein.

Datacenter <NUM> provides pooled resources on which customers can dynamically provision and scale applications as needed without having to add servers or additional networking. This allows customers to obtain the computing resources they need without having to procure, provision, and manage infrastructure on a per-application, ad-hoc basis. A cloud computing datacenter <NUM> allows customers to scale up or scale down resources dynamically to meet the current needs of their business. Additionally, a datacenter operator can provide usage-based services to customers so that they pay for only the resources they use, when they need to use them. For example, a customer may initially use one VM <NUM> on server <NUM><NUM> to run their applications <NUM>. When demand for an application <NUM> increases, the datacenter <NUM> may activate additional VMs <NUM> on the same server <NUM><NUM> and/or on a new server <NUM>N as needed. These additional VMs <NUM> can be deactivated if demand for the application later drops.

Datacenter <NUM> may offer guaranteed availability, disaster recovery, and back-up services. For example, the datacenter may designate one VM <NUM> on server <NUM><NUM> as the primary location for the customer's applications and may activate a second VM <NUM> on the same or different server as a standby or back-up in case the first VM or server <NUM><NUM> fails. Datacenter management controller <NUM> automatically shifts incoming user requests from the primary VM to the back-up VM without requiring customer intervention. Although datacenter <NUM> is illustrated as a single location, it will be understood that servers <NUM> may be distributed to multiple locations across the globe to provide additional redundancy and disaster recovery capabilities. Additionally, datacenter <NUM> may be an on-premises, private system that provides services to a single enterprise user or may be a publicly accessible, distributed system that provides services to multiple, unrelated customers or may be a combination of both.

Domain Name System (DNS) server <NUM> resolves domain and host names into IP (Internet Protocol) addresses for all roles, applications, and services in datacenter <NUM>. DNS log <NUM> maintains a record of which domain names have been resolved by role. It will be understood that DNS is used herein as an example and that other name resolution services and domain name logging services may be used to identify dependencies.

Datacenter health monitoring <NUM> monitors the health of the physical systems, software, and environment in datacenter <NUM>. Health monitoring <NUM> provides feedback to datacenter managers when problems are detected with servers, blades, processors, or applications in datacenter <NUM> or when network bandwidth or communications issues arise.

<FIG> shows an illustrative architecture <NUM> for a client computing device such as a laptop computer or personal computer for the present packet drop detection in local networking stack through packet correlation. The architecture <NUM> illustrated in <FIG> includes one or more processors <NUM> (e.g., central processing unit, dedicated Artificial Intelligence chip, graphics processing unit, etc.), a system memory <NUM>, including RAM (random access memory) <NUM> and ROM (read only memory) <NUM>, and a system bus <NUM> that operatively and functionally couples the components in the architecture <NUM>. A basic input/output system containing the basic routines that help to transfer information between elements within the architecture <NUM>, such as during startup, is typically stored in the ROM <NUM>. The architecture <NUM> further includes a mass storage device <NUM> for storing software code or other computer-executed code that is utilized to implement applications, the file system, and the operating system. The mass storage device <NUM> is connected to the processor <NUM> through a mass storage controller (not shown) connected to the bus <NUM>. The mass storage device <NUM> and its associated computer-readable storage media provide non-volatile storage for the architecture <NUM>. Although the description of computer-readable storage media contained herein refers to a mass storage device, such as a hard disk or CD-ROM drive, it may be appreciated by those skilled in the art that computer-readable storage media can be any available storage media that can be accessed by the architecture <NUM>.

By way of example, and not limitation, computer-readable storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. For example, computer-readable media includes, but is not limited to, RAM, ROM, EPROM (erasable programmable read only memory), EEPROM (electrically erasable programmable read only memory), Flash memory or other solid state memory technology, CD-ROM, DVD, HD-DVD (High Definition DVD), Blu-ray, or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device, or any other medium which can be used to store the desired information and which can be accessed by the architecture <NUM>.

According to various embodiments, the architecture <NUM> may operate in a networked environment using logical connections to remote computers through a network. The architecture <NUM> may connect to the network through a network interface unit <NUM> connected to the bus <NUM>. It may be appreciated that the network interface unit <NUM> also may be utilized to connect to other types of networks and remote computer systems. The architecture <NUM> also may include an input/output controller <NUM> for receiving and processing input from a number of other devices, including a keyboard, mouse, touchpad, touchscreen, control devices such as buttons and switches or electronic stylus (not shown in <FIG>). Similarly, the input/output controller <NUM> may provide output to a display screen, user interface, a printer, or other type of output device (also not shown in <FIG>).

It may be appreciated that the software components described herein may, when loaded into the processor <NUM> and executed, transform the processor <NUM> and the overall architecture <NUM> from a general-purpose computing system into a special-purpose computing system customized to facilitate the functionality presented herein. The processor <NUM> may be constructed from any number of transistors or other discrete circuit elements, which may individually or collectively assume any number of states. More specifically, the processor <NUM> may operate as a finite-state machine, in response to executable instructions contained within the software modules disclosed herein. These computer-executable instructions may transform the processor <NUM> by specifying how the processor <NUM> transitions between states, thereby transforming the transistors or other discrete hardware elements constituting the processor <NUM>.

Encoding the software modules presented herein also may transform the physical structure of the computer-readable storage media presented herein. The specific transformation of physical structure may depend on various factors in different implementations of this description. Examples of such factors may include, but are not limited to, the technology used to implement the computer-readable storage media, whether the computer-readable storage media is characterized as primary or secondary storage, and the like. For example, if the computer-readable storage media is implemented as semiconductor-based memory, the software disclosed herein may be encoded on the computer-readable storage media by transforming the physical state of the semiconductor memory.

As another example, the computer-readable storage media disclosed herein may be implemented using magnetic or optical technology. In such implementations, the software presented herein may transform the physical state of magnetic or optical media, when the software is encoded therein. These transformations may include altering the magnetic characteristics of particular locations within given magnetic media. These transformations also may include altering the physical features or characteristics of particular locations within given optical media to change the optical characteristics of those locations. Other transformations of physical media are possible without departing from the scope of the present description, with the foregoing examples provided only to facilitate this discussion.

The architecture <NUM> may further include one or more sensors <NUM> or a battery or power supply <NUM>. The sensors may be coupled to the architecture to pick up data about an environment or a component, including temperature, pressure, etc. Exemplary sensors can include a thermometer, accelerometer, smoke or gas sensor, pressure sensor (barometric or physical), light sensor, ultrasonic sensor, gyroscope, among others. The power supply may be adapted with an AC power cord or a battery, such as a rechargeable battery for portability.

In light of the above, it may be appreciated that many types of physical transformations take place in the architecture <NUM> in order to store and execute the software components presented herein. It also may be appreciated that the architecture <NUM> may include other types of computing devices, including wearable devices, handheld computers, embedded computer systems, smartphones, PDAs, and other types of computing devices known to those skilled in the art. It is also contemplated that the architecture <NUM> may not include all of the components shown in <FIG>, may include other components that are not explicitly shown in <FIG>, or may utilize an architecture completely different from that shown in <FIG>.

<FIG> is a simplified block diagram of an illustrative computer system <NUM> such as a PC or server with which the present packet drop detection in local networking stack through packet correlation may be implemented. Computer system <NUM> includes a processor <NUM>, a system memory <NUM>, and a system bus <NUM> that couples various system components including the system memory <NUM> to the processor <NUM>. The system bus <NUM> may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, or a local bus using any of a variety of bus architectures. The system memory <NUM> includes read only memory (ROM) <NUM> and random-access memory (RAM) <NUM>. A basic input/output system (BIOS) <NUM>, containing the basic routines that help to transfer information between elements within the computer system <NUM>, such as during startup, is stored in ROM <NUM>. The computer system <NUM> may further include a hard disk drive <NUM> for reading from and writing to an internally disposed hard disk (not shown), a magnetic disk drive <NUM> for reading from or writing to a removable magnetic disk <NUM> (e.g., a floppy disk), and an optical disk drive <NUM> for reading from or writing to a removable optical disk <NUM> such as a CD (compact disc), DVD (digital versatile disc), or other optical media. The hard disk drive <NUM>, magnetic disk drive <NUM>, and optical disk drive <NUM> are connected to the system bus <NUM> by a hard disk drive interface <NUM>, a magnetic disk drive interface <NUM>, and an optical drive interface <NUM>, respectively. The drives and their associated computer-readable storage media provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system <NUM>. Although this illustrative example includes a hard disk, a removable magnetic disk <NUM>, and a removable optical disk <NUM>, other types of computer-readable storage media which can store data that is accessible by a computer such as magnetic cassettes, Flash memory cards, digital video disks, data cartridges, random access memories (RAMs), read only memories (ROMs), and the like may also be used in some applications of the present packet drop detection in local networking stack through packet correlation. In addition, as used herein, the term computer-readable storage media includes one or more instances of a media type (e.g., one or more magnetic disks, one or more CDs, etc.). For purposes of this specification and the claims, the phrase "computer-readable storage media" and variations thereof, are intended to cover non-transitory embodiments, and do not include waves, signals, and/or other transitory and/or intangible communication media.

A number of program modules may be stored on the hard disk, magnetic disk <NUM>, optical disk <NUM>, ROM <NUM>, or RAM <NUM>, including an operating system <NUM>, one or more application programs <NUM>, other program modules <NUM>, and program data <NUM>. A user may enter commands and information into the computer system <NUM> through input devices such as a keyboard <NUM> and pointing device <NUM> such as a mouse. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, trackball, touchpad, touchscreen, touch-sensitive device, voice-command module or device, user motion or user gesture capture device, or the like. These and other input devices are often connected to the processor <NUM> through a serial port interface <NUM> that is coupled to the system bus <NUM>, but may be connected by other interfaces, such as a parallel port, game port, or universal serial bus (USB). A monitor <NUM> or other type of display device is also connected to the system bus <NUM> via an interface, such as a video adapter <NUM>. In addition to the monitor <NUM>, personal computers typically include other peripheral output devices (not shown), such as speakers and printers. The illustrative example shown in <FIG> also includes a host adapter <NUM>, a Small Computer System Interface (SCSI) bus <NUM>, and an external storage device <NUM> connected to the SCSI bus <NUM>.

The computer system <NUM> is operable in a networked environment using logical connections to one or more remote computers, such as a remote computer <NUM>. The remote computer <NUM> may be selected as another personal computer, a server, a router, a network PC, a peer device, or other common network node, and typically includes many or all of the elements described above relative to the computer system <NUM>, although only a single representative remote memory/storage device <NUM> is shown in <FIG>. The logical connections depicted in <FIG> include a local area network (LAN) <NUM> and a wide area network (WAN) <NUM>. Such networking environments are often deployed, for example, in offices, enterprise-wide computer networks, intranets, and the Internet.

When used in a LAN networking environment, the computer system <NUM> is connected to the local area network <NUM> through a network interface or adapter <NUM>. When used in a WAN networking environment, the computer system <NUM> typically includes a broadband modem <NUM>, network gateway, or other means for establishing communications over the wide area network <NUM>, such as the Internet. The broadband modem <NUM>, which may be internal or external, is connected to the system bus <NUM> via a serial port interface <NUM>. In a networked environment, program modules related to the computer system <NUM>, or portions thereof, may be stored in the remote memory storage device <NUM>. It is noted that the network connections shown in <FIG> are illustrative and other means of establishing a communications link between the computers may be used depending on the specific requirements of an application of the present packet drop detection in local networking stack through packet correlation.

Various exemplary embodiments of the present packet drop detection in local networking stack through packet correlation are now presented by way of illustration and not as an exhaustive list of all embodiments. An example includes a method performed by a computer server to monitor packet propagations and drops through a virtualized network stack hosted on the computer server, comprising: enabling operation of a packet monitoring application which triggers each component in a virtualized network stack to call an application programming interface (API) associated with the packet monitoring application; receiving, at the packet monitoring application, parameters by which to filter packets; receiving, at the packet monitoring application, packets from components within the virtualized network stack, in which the components are networking components configured to process and route packets traversing through the virtualized network stack; filtering, by the packet monitoring application, packets received from the components using the parameters, in which packets that meet the parameters are selected for display on a user interface associated with the computer server; and assigning correlation IDs (identifiers) to each packet at the packet monitoring application to enable correlation and tracking of packets as the packets traverse the components of the virtualized network stack.

In another example, the virtualized network stack includes a combination of hardware networking devices and software defined networking (SDN) components. In another example, the SDN components include a virtual switch, a virtual machine network interface controller (vNIC), a network driver interface specification (NDIS), and filters or extensions associated with the NDIS. In another example, the method further comprises displaying a report of the filtered packets on the user interface. In another example, the method further comprises encapsulating packets with an outer header and applying the filtration parameters to an inner header and the outer header of the encapsulated packets. In another example, the method further comprises determining latency for packets at each component of the virtualized network stack using the assigned correlation IDs. In another example, the components report packet drops that occur at any point within the respective component to the packet monitoring application, and the components report successful packet propagations based on a respective packet meeting a boundary of the component. In another example, the parameters include filtering packets by internet protocol (IP) address source. In another example, the parameters include filtering packets by internet protocol (IP) address destination. In another example, the parameters include filtering packets by MAC (media access control) address for a source or destination. In another example, the parameters include filtering packets by an ethernet protocol. In another example, the parameters include filtering packets at individual components of a plurality of available components within the virtualized network stack. In another example, the parameters include filtering packets by a port source or port destination. In another example, the parameters include filtering packets by TCP (Transmission Control Protocol) flags, including any one or more of TCP SYN (synchronize), TCP RST (reset), or TCP FIN (finish).

A further example includes a computer server configured with a packet monitoring application to track packets across a virtualized network stack on the computer server, comprising one or more processors and one or more hardware-based non-transitory memory devices storing computer-readable instructions which, when executed by the one or more processors, cause the computer server to: communicate packets between the computer server and one or more customer computing devices, in which, during communications, the packets traverse through components of the virtualized network stack, the components being virtual network components or physical network components associated with the virtualized network stack; report, by the components of the virtualized network stack, a packet's traversal status to a packet monitoring application; assign a correlation identifier (ID) to each packet; utilize the correlation ID to track packets across the components on the virtualized network stack; and configure the packet monitoring application to filter packets according to set parameters, such that respective packets are selected for display on a user interface responsive to the packets meeting one or more of the parameters.

In another example, the filtration parameters are set responsive to user input. In another example, the computer server further includes multiple computer servers having respective packet monitoring applications for tracking packets, in which packets are tracked on virtualized network stacks across each computer server on which the packets traverse. In another example, the executed instructions further cause the computer server to display on the user interface associated with the computer server an option to enable and disable the packet monitoring application, wherein the components report the status of packets responsive to the user interface receiving input enabling the packet monitoring application, and wherein a default setting of the packet monitoring application is disabled.

A further example includes one or more hardware-based non-transitory computer-readable memory devices storing instructions which, when executed by one or more processors disposed in a computer server, cause the computer server to: expose a user interface to a user to enable a packet monitoring application which causes components within a network stack to report packets; receive a selection of one or more parameters at the user interface that details which packets to select by the packet monitoring application; invoke an application programming interface (API) associated with the packet monitoring application by components within the network stack, in which the components use the API to report packet drops and packet propagations to the packet monitoring application; receive packets from the components of the network stack; filter the received packets using parameters, in which packets that fit the parameters are selected by the packet monitoring application to be displayed on the user interface associated with the computer server; assign a unique correlation identifier (ID) to the filtered packets, in which the correlation ID assigned to the packets follows a respective packet through the network stack; calculate, by the packet monitoring application, latency for the packets at the components using information about packet propagations from the components and correlation IDs assigned to respective packets; and display a report that includes the calculated latency and the packet drops for the filtered packets.

In another example, the executed instructions further cause the computer server to register components within the network stack with the packet monitoring application, wherein only registered components are capable of invoking the API associated with the packet monitoring application.

Claim 1:
A method performed by a computer server to monitor packet propagations (<NUM>) and drops (<NUM>) through a virtualized network stack (<NUM>) hosted on the computer server, comprising:
enabling operation of a packet monitoring application (<NUM>) which triggers each component (<NUM>) in a virtualized network stack (<NUM>) to call an application programming interface, API, (<NUM>) associated with the packet monitoring application (<NUM>) in which the virtualized network stack includes components comprising: a virtual switch, a physical network interface controller, a virtual machine network interface controller, a network driver interface to the network interface controller, a transmission control protocol/internet protocol, filters and extensions;
receiving, at the packet monitoring application (<NUM>), parameters by which to filter packets (<NUM>);
receiving, at the packet monitoring application (<NUM>), packets (<NUM>) from the components (<NUM>) within the virtualized network stack (<NUM>), in which the components (<NUM>) are configured to process and route packets (<NUM>) traversing through the virtualized network stack (<NUM>);
filtering, by the packet monitoring application (<NUM>), packets (<NUM>) received from the components (<NUM>) using the parameters, in which packets (<NUM>) that meet the parameters are selected for display on a user interface associated with the computer server; and characterised in that said method further comprises:
assigning (<NUM>) correlation IDs, identifiers, (<NUM>) to each packet (<NUM>) at the packet monitoring application (<NUM>) to enable correlation and tracking of packets (<NUM>) as the packets (<NUM>) traverse the components (<NUM>) of the virtualized network stack (<NUM>).