(en)An operating system implements classes of network streams. Applications assign their network streams to the classes. The operating system, in turn, regulates the streams according to which classes the streams are in. As conditions change, network resources may be made available or more fully utilized by regulating streams according to which classes they have been assigned to. Network resources may be made available, perhaps rapidly or preemptively, for streams in higher priority classes by restricting streams in lower priority classes.

1.ApplicationNumber: US-201414497315-A
1.PublishNumber: US-9674099-B2
2.Date Publish: 20170606
3.Inventor: TALAT AHMED
BHATT VIBHOR
SINNEMAKI JEFF
ALEKSENKO ALEXEI
SACSON ILIA
FULLER JEFFREY C.
SALMAN MILENA
RAVI MADHUSUDHAN
KARAM MOHAMMED
JAIN NEEL

4.Inventor Harmonized: TALAT AHMED(US)
BHATT VIBHOR(US)
SINNEMAKI JEFF(US)
ALEKSENKO ALEXEI(US)
SACSON ILIA(US)
FULLER JEFFREY C(US)
SALMAN MILENA(US)
RAVI MADHUSUDHAN(US)
KARAM MOHAMMED(US)
JAIN NEEL(US)

5.Country: US
6.Claims:
(en)An operating system implements classes of network streams. Applications assign their network streams to the classes. The operating system, in turn, regulates the streams according to which classes the streams are in. As conditions change, network resources may be made available or more fully utilized by regulating streams according to which classes they have been assigned to. Network resources may be made available, perhaps rapidly or preemptively, for streams in higher priority classes by restricting streams in lower priority classes.

7.Description:
(en)RELATED APPLICATIONS
This application is related to U.S. patent application Ser. No. 14/497,313, titled “MANAGING CLASSIFIED NETWORK STREAMS”, filed Sep. 25, 2014, which is incorporated herein by reference.
BACKGROUND
When multiple applications on a computing device share the same limited network resources on or external to the computing device, various techniques have been used to attempt to balance the networking needs of those applications. Computer users and applications usually prefer certain trade-offs and prioritizations among applications consuming network resources. However, in practice, prior techniques for sharing network access often have not optimally realized those preferences and priorities. For example, a user of a device may prefer that Voice over IP (VoIP) calls on their device have low network latency and that web browsing on the device be snappy and responsive. The user also may prefer that background bulk network transfers, such as cloud synchronizations and operating system updates, yield their consumption of the device's network resources in a way that enables satisfactory foreground performance and maintains reasonable progress.
In addition to often failing to satisfactorily share network access, prior access-sharing techniques have often not been convenient for software developers to access or implement. For example, while Quality of Service (QoS) facilities can be helpful, they are often not available or are not implemented in a uniform manner. Most QoS technology occurs below the application level and therefore may not be reliably manipulable by applications. Most QoS approaches, Differentiated Services for instance, depend on the behavior and support of the network between two endpoints. Such support may not exist on all network paths. Regarding convenience, network sharing behavior has also been implemented within applications, but this has usually required complex network programming with little or no direct coordination between applications. Not only is it duplicative for different applications to implement their own network-sharing logic, but the different resource-sharing behaviors of applications may conflict.
While there are protocols such as LEDBAT (Low Extra Delay Background Transport) that are implemented by operating systems to allow applications to implement specific types of network-consuming behavior, coding to leverage such a protocol may increase the cost and overhead of developing an application and may make a developer less likely to use such a protocol. In addition, widely deployed low-priority TCP (Transport Control Protocol) mechanisms like LEDBAT have shortcomings and often do not provide an ideal user experience (see Internet Engineering Task Force Request for Comments 6297 for other examples). The LEDBAT protocol, for instance, only restricts TCP send windows and has no effect on the receive stream, yet most client-side Internet traffic is inbound. Even when a mechanism like LEDBAT is available without requiring complex developer coding, it may not be possible for an operating system or network stack to determine that an application should use such a mechanism. In other words, user and application intent regarding network resource conflicts has been difficult to infer and applications have rarely specified their network priorities. Nor has sharing of a device's network resources been implemented in a way that is consistent among competing applications without being susceptible to problems such as the “latecomer” phenomena (e.g., see Request For Comments 681 7, section 4.4).
Techniques related to convenient and effective sharing of a device's network resources are discussed below.
SUMMARY
The following summary is included only to introduce some concepts discussed in the Detailed Description below. This summary is not comprehensive and is not intended to delineate the scope of the claimed subject matter, which is set forth by the claims presented at the end.
An operating system implements classes of network streams. Applications assign their network streams to the classes. The operating system, in turn, regulates the streams according to which classes the streams are in. As conditions change, network resources may be made available or more fully utilized by regulating streams according to which classes they have been assigned to. Network resources may be made available, perhaps rapidly or preemptively, for streams in higher priority classes by restricting streams in lower priority classes.
Many of the attendant features will be explained below with reference to the following detailed description considered in connection with the accompanying drawings.



BRIEF DESCRIPTION OF THE DRAWINGS
The present description will be better understood from the following detailed description read in light of the accompanying drawings, wherein like reference numerals are used to designate like parts in the accompanying description.
FIG. 1 shows a computing device with an operating system that implements a network stack.
FIG. 2 shows a process of an application using an application programming interface (API).
FIG. 3 shows an example of a stream classification model.
FIG. 4 shows example streams with respective network performance categories.
FIG. 5 shows another example of a classification model.
FIG. 6 shows a detailed view of a stream manager.
FIG. 7 shows an example process by which the stream manager may regulate streams.
FIG. 8 shows another example of a stream classification model.
FIG. 9 shows a process for an embodiment of collective stream management.
FIG. 10 shows additional details of a computing device.



DETAILED DESCRIPTION
Embodiments discussed below relate to allowing applications to classify their network streams to a network stack or operating system, which in turn orchestrates sharing of a device's network resources in a system-wide fashion according to the classifications of the network streams. Discussion will begin with a system overview and explanation of how applications can select how the system will regulate their network behavior. Examples of network stream classification models and details for implementing same will be described next.
FIG. 1 shows a computing device 100 with an operating system 102 that implements a network stack 104 . The network stack 104 may be derived from any known operating system networking stack, with additions or changes apparent from this description. For example, a TCP/IP network stack may be modified or augmented with a wrapper. Generally, implementation at the transport level of any network protocol stack will be convenient. On the computing device 100 , any of a variety of arbitrary applications 106 may be executing and communicating through a data network 108 . Some examples of applications 106 are web browsers, background downloaders, online games, realtime voice or video communication programs, database clients, media streaming applications, etc. To exchange data with remote devices 109 , the applications 106 communicate through the data network 108 , which may be a network carrying IP (Internet Protocol) traffic or variants thereof. In cases where a virtualization layer (e.g., a hypervisor) is present and applications execute on guest operating systems on different virtual machines, network communication may be fully or partly local to the computing device 100 .
The operating system 102 may include one or more interface drivers 110 (device drivers) that, among other known functions, pass packets to, and receive packets from, respective network interfaces 112 . It may be assumed that the applications 106 execute in user space and the operating system 102 and networking features described herein execute in kernel space. However, this is not a requirement. Kernel mode code or user mode code may assign network classifications to network streams controlled thereby, and a stream manager 114 may execute in kernel space or user space. In one embodiment, network stream management may be implemented with a user mode wrapper that exchanges packets with a known TCP/IP network stack.
The stream manager 114 manages and regulates network streams 116 for the applications 106 . Network streams 116 (referred to hereafter as “streams”) are operating system objects that correspond to respective network connections (e.g., IP 5-tuples) between the computing device 100 and the remote devices 109 . Typically, each stream has a FIFO buffer and a descriptor or handle used by the operating system and the stream's application to identify the stream when performing operations on the stream. The network stack 104 may provide a transport-layer module (e.g., a TCP module) that implements a transport protocol on behalf of the streams 116 . The operating system 102 provides an application programming interface (API) 118 that applications 106 use to perform stream related operations such as instantiating a stream object, setting stream parameters, initiating a network connection with a stream, closing the stream, getting and setting values of properties of the stream such as a network address to be connected to, a remote and local port to be used, a protocol to be used, networking parameters, etc. The Winsock API, the Berkeley sockets API, and other similar APIs are all suitable, when extended or modified as described herein, for use as the API 118 .
FIG. 2 shows a process of an application using the API 118 to inform the network stack 104 of a stream class or category to be associated with a specified stream. At step 140 , the application forms or obtains a stream. The stream may or may not have a network connection. The stream, in the application's executing code, may be referenced as a descriptor, a handle, object, etc. The application may obtain the stream from another application or process or may initiate the stream as a new object. In the latter case, various parameters or properties of the stream may be set by the application prior to use of the stream to form a network connection. As noted above, such parameters, for example, might be a remote network address, a local network address (when multiple network interfaces 112 are available on the computing device 100 100 ), local and remote ports, protocol settings, and so forth.
At step 142 the application uses API 118 to assign a stream class or category (“class”, hereafter) specifically to the stream. The application may assign other classes to other of the application's streams. Step 142 may be performed at any time during the life of the stream, including when the stream is instantiated, before a network connection is formed for the stream, after the stream is connected and perhaps carrying traffic, when the stream is carrying traffic, etc. Moreover, step 142 may be performed repeatedly on a same stream to change the class that is currently assigned to the stream, thus, as discussed next, correspondingly changing how the stream manager 114 regulates the flow of packets through the stream.
At step 144 , the operating system, specifically, the stream manager 114 , controls network resource usage by the network stream. The stream manager 114 functions as a central coordinator that orchestrates network behavior of multiple (perhaps all) streams being managed by the operating system. The stream manager 114 may track actual network performance of the streams and regulate their behavior, in particular with respect to latency and bandwidth (throughput) performance, and possibly average throughput over different size time windows. The stream manager 114 may also receive signals about network conditions, for instance by analyzing return trip times (RTTs) of probe packets, by receiving information about queue sizes of various devices along network paths of the streams, etc. Notably, the stream manager 114 should be able to determine recent and/or current bandwidth, latency, or both, for each stream. In one embodiment, not all streams have an explicit application-assigned class. However, the stream manager 114 may also manage these streams, possibly by treating them as having a default class. In one embodiment, the stream manager 114 is not a distinct module or component, but rather is logic dispersed throughout the operating system 102 and/or the network stack 104 (the term “stream manager” as used herein refers to both designs). In other words, the placement of stream management logic is not important.
FIG. 3 shows an example of a stream classification model 180 A. FIG. 3 also shows a sample of code 182 that assigns a class to a stream. The classification model 180 A has eight classes, with four for bandwidth and four for latency. In this example classification model 180 A, two classes may be assigned to the same stream; one class for bandwidth and one class for latency. As seen in the sample code 182 , a “high” bandwidth and “low” latency classes are assigned to a stream represented by “socket_s”. In other embodiments, the classification model 180 A might have only bandwidth classes, or only latency classes, or individual classes that have both performance dimensions, as shown in FIG. 5 . FIG. 4 shows example streams 190 with respective network performance categories. The streams 190 may have identifiers and classes 192 as assigned through the API 116 . In one embodiment, classifications of respective streams are flags or properties of respective data structures or objects that the operating system 102 uses to represent the streams.
FIG. 5 shows another example of a classification model 1808 . The classification model 1808 has six classes (A to F): a realtime class, a responsive (interactive) class, a streaming class, a normal class, an eventual class, and an invisible class. This classification model 1808 may be convenient for developers as the individual classes correspond closely to common types of network-consuming applications. Each class may have, as implemented in logic of the stream manager 114 , respective performance ranges, floors, ceilings, etc., in one or more dimensions of network performance. For example, the classes might be implemented as follows (bandwidth in terms of megabits per second (MBS), latency in terms of milliseconds (ms)):
realtime: 1 MBS, 200 ms,
responsive: 0.1 MBS, 50 ms,
streaming: 3 MBS, 1500 ms,
normal: 0.2 MBS, 5000 ms, and
eventual, invisible: 0 MBS, 0 ms.
These numbers are only examples; any values may be used, and some classes may have no bandwidth and/or latency specification.
The stream manager 114 may have control logic 200 ( FIG. 6 ) to implement policies or rules 202 for how performance targets of streams, per their classes, are to be achieved when demand creates conflict among the streams. For example, the rules 202 may specify precedence for bandwidth such that when streaming-class streams are at or near their limits bandwidth is made available by throttling other streams according to their classes. For example, when a category-A stream requires networking resources, invisible streams might be throttled first, then eventual, then normal, then responsive. The classes might also have respective weights to specify relative portions of bandwidth (or latency) to be throttled, thus allowing a stream in a higher priority class to obtain a large portion of bandwidth freed from low priority streams and a small portion of bandwidth freed from medium priority streams. In another embodiment, use of network resources is prioritized or apportioned according to the classes of the streams. If a responsive stream requires additional bandwidth, that bandwidth may be drawn (by throttling, for instance) from which ever streams can spare bandwidth while remaining within their performance specifications, perhaps starting from lowest priority class streams. In sum, collective management of network resource consumption by streams according to their classes may be implemented by a wide range of algorithms, rules/priorities, performance values, etc.
A potential benefit of centralized global management of streams according to application-specified classes is that a user's experience may be improved. For example, suppose that a user's device is running a multimedia streaming application with a network stream that has been classified as “streaming”. Suppose also that the user starts a web browser application that classifies its HTTP browsing streams as “responsive” and classifies its download streams as “normal”. When the user requests a web page, because the corresponding responsive-class stream has higher latency priority than the streaming-class stream, the streaming-class stream may be temporarily throttled (e.g., for 50 ms) to allow the responsive-class stream to meet its latency requirement. The brief slowdown of the streaming-class stream will likely not be noticed by the user (due to buffering), and the web page will download quickly. If the user initiates a file download, bandwidth may be “borrowed” from the streaming-class stream until its bandwidth floor is reached, thus allowing the normal-class download stream to proceed in a way that maximizes its bandwidth without disrupting the playing of media from the streaming-class stream.
FIG. 6 shows a detailed view of the stream manager 114 . The streams 190 each have a respective queue 240 where packets are queued before being passed through to a device driver for transmission by a corresponding network interface or after being received from a device driver. The control logic 200 manages the network performance of the streams 190 as described above. The control logic 200 may repeatedly receive updates regarding bandwidth and latency. The updates may come from the interface drivers 110 , the network stack 104 , or external sources. Such updates may indicate a variety of network conditions and statistics such as current bandwidth availability for the computing device 100 or for the individual network interfaces 112 , current or projected latency information, network congestion, and so forth. The control logic 200 may use this information to regulate how network resources are consumed by streams.
FIG. 7 shows an example process by which the control logic 200 may regulate streams. At a regular interval, the stream manager 114 may, at step 260 , begin iterating over the active streams (“stream”, in this paragraph, refers to the stream of the current iteration). At step 262 current performance statistics of the stream are obtained. For instance, current or estimated bandwidth and latency are obtained. This information may be estimated from recent throughput, projected according to current traffic statistics, based on the amount of queued packets, the rate of incoming packets, and other known techniques. The class of a stream may affect how often it is iteratively evaluated.
At step 264 , the stream manager 114 determines the stream's class or category and determines if the stream is (or is expected to be) performing according to its specified category. At step 266 , if the stream is not performing as specified, then the stream manager 114 implements adaptations intended to satisfy the stream's class specifications. For example, taking into account their classes, other streams may be throttled, paused, etc. This may be accomplished by adjusting the receive windows and/or the send windows of streams, expanding or contracting stream buffers, pausing packet flow through a stream, etc. It is not necessary for applications or other components to tag packets, nor is it necessary for applications to use protocol-level QoS features. From the application's perspective, the streams are ordinary TCP (or similar) streams. At step 268 a next stream, if any, is processed.
Regarding mentions herein of streams not performing according to specifications of their respective classes, determinations of performance compliance or determinations that drive performance adjustments should be understood as encompassing more than mere performance relative to other connections on the host machine. Protocols such as the LEDBAT protocol, for example, consider a stream to be not performing as specified if the stream's network connection is experiencing one-way delays that are 100 ms higher than the lowest one-way delay the connection has experienced. The assumption is that the LEDBAT connection might be the factor causing the increased delay, and restricting that connection's windows may decrease delay for other connections going across the same shared network resources. Put another way, specifications of stream classes may be relative respect to each other, absolute with respect to performance values, or combinations of both. In addition, a formal language or syntax may be provided to express complex specifications, for example a syntax of Boolean operators, conditional statements, etc., perhaps in the form of a markup-based (e.g. extensible markup files) declarative language. Or, such complex logic may be “hardcoded” into the programming of the streams manager, the network stack, etc.
FIG. 8 shows another example of a stream classification model 180 C. Each category has a latency component and a bandwidth component. Categories may overlap along either dimension. In this example, classification of a stream assigns both a bandwidth and a latency performance target to a stream. If it is assumed that one class, for instance class-E, is intended to impart on corresponding streams a latency specification that corresponds to real-time or rapid responsiveness (i.e., network traffic will begin to flow with minimal apparent delay in response to a user request), then the stream manager logic may use various network-affecting mechanisms of the local operating system to “backoff” or down-regulate other streams, such as class-D streams (or all other streams, or all other active streams, etc.). That is, when a new connection or new traffic begins that is classified as sensitive to latency, low-priority connections can be locally impaired immediately. For example, if a web browser initiated by a user is about to request web objects, background file transfers can pre-emptively be impaired so that upcoming browser traffic starts with a clean network. Prior approaches often rely on quality-of-service decisions that are made based on competing traffic which is usually not immediately helpful for new traffic. A similar approach may be used for bandwidth performance, or for combinations of network performance characteristics. Note that local traffic impairment can be accomplished by pausing the flow of data from applications to their network connections, pausing transmission of buffered packets, adjusting networking window sizes, suspending or downgrading threads that handle stream traffic, or by adjusting other operational parameters of a stream that may potentially affect a stream's consumption of network resources.
FIG. 9 shows a process for an embodiment of collective stream management. In this embodiment, the stream manager 114 may effectuate reallocation of network resources as follows. At step 280 it is determined that a target stream needs additional network resources, for instance bandwidth or latency or both, according to its class. For an explanatory example, a class-A stream of classification model 180 C will be assumed to need additional bandwidth. At step 282 , aggregate statistics are acquired for each class of streams. At step 284 , those aggregate statistics are evaluated in class-appropriate order, and at step 286 they are adjusted as needed. The lowest priority class of streams according to the network need is evaluated first, i.e., class-E. If the aggregate bandwidth of class-E streams has, as a whole, extra bandwidth, then class-E streams are throttled to provide additional bandwidth. If the class-E streams have insufficient bandwidth to yield, then the aggregate statistic of the next priority class—class-C—is evaluated. That is, if throttling class-E streams did not free up sufficient bandwidth, the aggregate bandwidth of class-C streams is evaluated and the streams in that class are throttled as needed. If both class-C and class-E streams cannot surrender sufficient bandwidth while meeting their class requirements, then the lower priority class of streams—class-E—may be pushed below their class's bandwidth targets to help satisfy the higher-priority class-A stream's bandwidth requirement.
If the stream in the example above requires improved latency instead of or in addition to added bandwidth, a similar process is performed, but the evaluation of each class's aggregate statistics, and any adjustments to the streams therein, is performed in an order that depends on the latency traits of the classes.
Although this description may in places refer to network resources as being allocated or reallocated, “allocation” of resources is a conceptual characterization of a side effect of using any of a variety of network-affecting mechanisms (described above) to attempt to satisfy the specifications of stream classes. Moreover, prioritization or stream-regulation measures taken based on stream classes may not necessarily involve immediate increases or decreases in consumption of network resources by corresponding streams. For example, protocols such as the LEDBAT protocol (which may be modified to provide stream classes) may not necessarily harm the bandwidth or latency of a low-priority connection when LEDBAT has decided that a low-priority connection needs to be “restricted”. For example, reducing the size of a connection's send window may have no immediate impact on its throughput or latency; for many possible reasons the connection may subsequently get better throughput or latency.
FIG. 10 shows additional details of the generic computing device 100 on which embodiments described above may be implemented. The computing device 100 may have a display 300 as well as storage 302 and processing hardware 304 , which may be a combination of any one or more: central processing units, graphics processing units, analog-to-digital converters, bus chips, Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Application-specific Standard Products (ASSPs), or Complex Programmable Logic Devices (CPLDs), etc. The storage 302 may be any combination of magnetic storage, static memory, volatile memory, etc. The meaning of the term “storage”, as used herein does not refer to signals or energy per se, but rather refers to physical apparatuses (including physical media such as magnetic storage media, optical storage media, static memory devices, etc., but not signals per se). The hardware elements of the computing device 100 may cooperate in ways well understood in the art of computing. In addition, input devices 306 may be integrated with or in communication with the computing device 100 . The computing device 100 may have any form factor or may be used in any type of encompassing device. The computing device 100 may be in the form of a handheld device such as a smartphone, a tablet computer, a gaming device, a server, a rack-mounted or backplaned computer-on-a-board, a System-on-a-chip, or others. Generally, the computing device 100 will be a discrete network node or device.
Embodiments and features discussed above can be realized in the form of information stored in volatile or non-volatile computer or device readable apparatuses, with such information able to configure the computing device 100 to perform the embodiments described herein. These apparatuses may include apparatuses such as optical storage (e.g., compact-disk read-only memory (CD-ROM)), magnetic media, holographic storage, flash read-only memory (ROM), or other devices for storing digital information. The stored information can be in the form of machine executable instructions (e.g., compiled executable binary code), source code, bytecode, or other information that can be used to enable or configure computing devices to perform the embodiments described herein. This is also deemed to include at least volatile memory such as random-access memory (RAM) and/or virtual memory storing information such as central processing unit (CPU) instructions during execution of software carrying out an embodiment, as well as non-volatile devices storing information that allows a program or executable to be loaded and executed.