US8885632B2 - Communications scheduler - Google Patents

Abstract

A System for providing communications over a communications network includes a communications interface and processor. The communications interface communicates over the communications network. The processor directs a communications scheduler to determine at least one metric for a path within the communications network. The processor also selects a data flow for the path and determines whether to transmit a packet in the selected data flow based on the at least one metric. The processor then directs a communications protocol handler to generate the packet for the selected data flow.

Description

BACKGROUND

1. Technical Field

The present invention relates generally to data flow control over a network and more particularly to a communications scheduler controlling data flow over a network.

2. Description of Related Art

As transmission of network data over a communications network has become commonplace, users increasingly rely upon the speed and accuracy of network data transferral. One of the most common protocols to transmit network data is the transmission control protocol/internet protocol (TCP/IP). The TCP/IP protocol, like many protocols, organizes network data into packets and controls the transmission of packets over the communications network.

Slow-start is a part of the congestion control strategy of the TCP/IP protocol. Slow-start is used to avoid sending more packets than the communications network is capable of handling. Slow-start increases a TCP congestion window size until acknowledgements are not received for some packets. The TCP congestion window is the number of packets that can be sent without receiving an acknowledgment from the packet receiver. Initially, packets are slowly sent over the communications network. Transmission of the packets is increased until the communications network is congested. When acknowledgements are not received, the TCP congestion window is reduced. Subsequently, the number of packets sent without an acknowledgement is reduced and the process repeats.

The TCP/IP protocol can allocate bandwidth that is roughly inversely proportional to the long round trip time (RTT). Although many people generally expect bandwidth to be equally shared among users, the bandwidth is often in relation to the RTT ratio. In one example, two different users may be transmitting data. The first user may desire to transmit data to a local digital device with a 1 ms round trip time while the other user may desire to transmit data to another state with a 100 ms round trip time. The standard TCP/IP protocol will, on average, deliver 100× more bandwidth to the local device connection than to the out-of-state connection. The TCP/IP protocol does not consciously try to enforce any kind of explicit fairness policy. As a result, users that transmit data locally may receive better service at the unfair expense of those wishing to transmit data over longer distances.

FIG. 1 is a block diagram of acomputer100 configured to transmit network data in the prior art. Thecomputer100 depicts hardware and software elements related to transmission of network data. Other hardware and software of thecomputer100 are not depicted for the sake of simplicity. Thecomputer100 comprises anapplication110, a TCP/IP stack120, anetwork device driver130, and anetwork interface card140. Thenetwork interface card140 is coupled to a communications network over alink150. Thecomputer100 can be any digital device configured to transmit network data.

The TCP/IP stack120 receives the network data from theapplication110 and proceeds to organize the network data into packets. Depending on the type of network, a packet can be termed a frame, block, cell, or segment. The TCP/IP stack120 buffers the network data prior to organizing the network data into packets and subsequently buffers the packets.

Thenetwork device driver130 enables an operating system of thecomputer100 to communicate to thenetwork interface card140. Thenetwork interface card140 is any device configured to send or receive packets over the communications network. Thenetwork device driver130 configures thenetwork interface card140 to receive the packets and subsequently transmit the packets over thelink150 to the communications network.

In one example, the TCP/IP stack120 of the sendingcomputer100 will not send another packet across the communications network until an acknowledgement from the destination is received. The number of packets between acknowledgments increases until a packet is lost and an acknowledgment is not received. At which point the TCP/IP stack120 slows down the transmission of packets and, again, slowly increases the speed of transmission between acknowledgments until, again, a packet is lost. As a result, the transmission of network data by the TCP/IP stack120 can be graphed as a saw tooth; the transmission of network data increases until packets are lost and then transmission drops to a slower speed before repeating the process. Under the TCP/IP approach, packets are often transmitted at speeds below the network's capacity. When the packets are not being sent slowly, however, the communications network quickly becomes congested and the process repeats.

While the TCP/IP stack120 waits to transmit the packets, the packets are buffered. If the TCP/IP stack120 transmits too slowly, the buffers may overrun and packets may be lost. Further, the process of buffering and retrieving the buffered packets slows packet transmission and increases the costs of hardware.

The TCP/IP stack120 delivers different performance depending on the distance that packets are to travel. The TCP/IP stack120 generates packets based on received network data. The destination of the packets dictates the order in which the packets are transmitted. Packets to be transmitted longer distances may be transmitted slower than packets to be transmitted shorter distances. As a result, this procedure may not be fair to users wishing to transmit mission critical data long distances.

Performance enhancing proxies have been used to improve performance of local networks by overriding specific behaviors of the TCP/IP stack120. In one example, individual digital devices on a local area network are configured to transmit packets based on a proxy protocol. The proxy protocol overrides certain behaviors of the TCP/IP stack120 to improve the speed of transmission of network data. However, the performance enhancing proxy does not find bottlenecks on networks, control the transmission of network data based on bottlenecks, nor improve fairness in packet transmission.

SUMMARY OF THE INVENTION

The invention addresses the above problems by providing a communications scheduler that controls data flow over a network. The communications scheduler controls the transmission of packets over a path at a rate based on at least one metric. A system for providing communications over a communications network includes a communications interface and a processor. The communications interface communicates over the communications network. The processor directs a communications scheduler to determine at least one metric for a path within the communications network. The processor also selects a data flow for the path and determines whether to transmit a packet in the selected data flow based on the at least one metric. The processor then directs a communications protocol handler to generate the packet for the selected data flow.

The communications interface may transmit the packet in the selected data flow. The communications protocol handler may comprise a transmission control protocol/internet (TCP/IP) protocol stack. At least one metric may be a bandwidth or a bandwidth estimate.

The processor may direct the communications protocol handler to receive information from an application to be included in the packet. The processor may also direct the communications scheduler to determine if the data flow has information to send prior to selecting the data flow of the path. To select the data flow, the processor may direct the communications scheduler to determine a priority of data flows and determine the data flow to generate the packet based on the priority of data flows determination and the metric. The priority of data flows may be based on a fairness policy.

A system for providing communications over a communications network includes a communications scheduler module and a communications network handler module. The communications scheduler module determines at least one metric for a path within the communications network and selects a data flow for the path. The communications scheduler module determines whether to transmit a packet in the selected data flow based on the at least one metric. Further, the communications scheduler module directs a communications protocol handler to generate the packet in the selected data flow. The communications network handler receives the direction from the communications scheduler to generate the packet in the selected data flow and generates the packet based on the direction.

A method for providing communications over a communications network includes determining at least one metric for a path within the communications network, selecting a data flow for the path, determining whether to transmit a packet in the selected data flow based on the at least one metric, and directing a communications protocol handler to generate the packet for the selected data flow.

A software product for providing communications over a communications network includes a communications scheduler software and a storage medium to store the communications scheduler software. The communications scheduler software directs a processor to determine at least one metric for a path within the communications network and select a data flow for the path. The communications scheduler software can also determine whether to transmit a packet in the selected data flow based on the at least one metric and direct a communications protocol handler to generate the packet for the selected data flow.

The system advantageously transmits packets at a rate based on a path's capacity to carry packets. By determining a metric for a selected path, packets of network data can be transmitted to maximize throughput without waiting for lost packets or acknowledgments to prove network congestion. As a result, the overall speed of packet transmission can be improved without sacrificing reliability. Network congestion which can affect other traffic within the path can be avoided by reducing the transmission of packet above what the path can carry. Further, packets may be generated at the speed of packet transmission advantageously reducing or eliminating the need for packet buffering. The reduction or elimination of buffers reduces hardware expense and may increase the speed of packet transmission.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a computer configured to transmit network data in the prior art.

FIG. 2 is an illustration of a network environment in an exemplary implementation of the invention.

FIG. 3 is an illustration of a network device in an exemplary implementation of the invention.

FIG. 4 is a flow chart for the transmission of network data in an exemplary implementation of the invention.

FIG. 5 is a flow chart for the determination of the bandwidth estimate in an exemplary implementation of the invention.

FIG. 6 is a block diagram of the network device in an exemplary implementation of the invention.

FIG. 7 is an illustration of an exemplary implementation of the operation of a network device in the prior art.

FIG. 8 is an illustration of an exemplary implementation of the operation of a network device of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The embodiments discussed herein are illustrative of one example of the present invention. As these embodiments of the present invention are described with reference to illustrations, various modifications or adaptations of the methods and/or specific structures described may become apparent to those skilled in the art. All such modifications, adaptations, or variations that rely upon the teachings of the present invention, and through which these teachings have advanced the art, are considered to be within the scope of the present invention. Hence, these descriptions and drawings should not be considered in a limiting sense, as it is understood that the present invention is in no way limited to only the embodiments illustrated.

A system for providing communications over a communications network includes a communications interface and a processor. The communications interface communicates over the communications network. The processor directs a communications scheduler to determine at least one metric for a path within the communications network. The processor also selects a data flow for the path and determines whether to transmit a packet in the selected data flow based on the at least one metric. The processor then directs a communications protocol handler to generate the packet for the selected data flow.

The system can advantageously provide reliable transmission of packets through a communications network more efficiently and more fairly than that available in the prior art. Instead of increasing speeds to the point of network congestion before slowing transmission, packets may be transmitted through the communications network at speeds that more closely approximate the capacity of the packet path. As a result, network congestion is reduced and high data transmission rates can be maintained.

Further, the system can advantageously provide fair transmission of packets through the communications network. Instead of transmitting packets based on the conservation of bandwidth over long distances, packets can be transmitted based on an equitable policy. As a result, packets from each user may be transmitted over the communication network at a rate equal to that of other users regardless of the RTT of the transmission. Further, packets may be transmitted at a faster rate based on the relative importance of the packets, the identity of the user providing network data, or the type of digital device generating the packets. Other fairness policies are also possible.

FIG. 2 is an illustration of anetwork environment200 in an exemplary implementation of the invention. Thenetwork environment200 includes asource210, anoptional source network220, asource network device230, acommunications network240, adestination250, anoptional destination network260, and adestination network device270. Thesource210 is coupled to thesource network device230 over thesource network220. Thesource network device230 is coupled to thecommunications network240. Thecommunications network240 is coupled to thedestination network device270, which is coupled to thedestination250 over thedestination network260.

Source210 can be any digital device configured to transmit network data. Similarly, thedestination250 is any digital device configured to receive network data. Examples of digital devices include, but are not limited to, computers, personal digital assistants, and cellular telephones. Thesource network220 and thedestination network260 are any networks that couple a digital device (e.g., source210) to a network device (e.g., source network device230). Thesource network220 and thedestination network260 can be a wired network, a wireless network, or any combination.

Thecommunications network240 can be any network configured to carry network data and/or packets between thesource network device230 and thedestination network device270. In one example, thecommunications network240 is the Internet.

The embodiments inFIGS. 2-5 depict an example of packets being transmitted from thesource210 to thedestination250 through thesource network device230, thecommunications network240, and thedestination network device270. Other embodiments may include packets being transmitted directly from thedestination250 to thesource210. In an example, thesource210 and thedestination250 may comprise thesource network device230 and thedestination network device270, respectively. While there are numerous variations in where packets are generated and transmitted, the figures below describe one example of packet transmissions from thesource210 to thedestination250 for the sake of simplicity.

Thesource network device230 and thedestination network device270 are any device or system configured to process and exchange packets over thecommunications network240. A path is any route the packet may take from thesource network device230 to thedestination network device270. The configuration of thesource network device230 and thedestination network device270 are described in further detail below inFIG. 6. One example of thesource network device230 and thedestination network device270 is an appliance in a network memory architecture, which is described in U.S. patent application Ser. No. 11/202,697 entitled “Network Memory Architecture for Providing Data Based on Local Accessibility” filed on Aug. 12, 2005, which is hereby incorporated by reference.

FIG. 3 is an illustration of anetwork device300 in an exemplary implementation of the invention. Thenetwork device300 may be the source network device230 (FIG. 2) or the destination network device270 (FIG. 2). Thenetwork device300 includes acommunications protocol handler310, acommunications scheduler320, and acommunications interface330. Thecommunications protocol handler310 is coupled to thecommunications scheduler320 overscheduler link340. Thecommunications scheduler320 is further coupled to thecommunications interface330 over communications link350. Thecommunications interface330 is coupled to thecommunications protocol handler310 overhandler link360, the communications network240 (FIG. 2) overnetwork link370, and thesource network220 over thesource link380. Thecommunications protocol handler310, thecommunications scheduler320, and thecommunications interface330 may be software modules. Software modules comprise executable code that may be processed by a processor (not depicted).

Thecommunications protocol handler310 is any combination of protocols configured to organize network data into packets. In one example, thecommunications protocol handler310 is a TCP/IP stack. In other examples, thecommunications protocol handler310 is a User Datagram Protocol (UDP) stack or a Real-time Transport Protocol (RTP) stack. Thecommunications protocol handler310 may receive network data from an application (not depicted). Thecommunications protocol handler310 organizes the network data from the application into packets which are to be transmitted over thecommunications network240. Thecommunications protocol handler310 may receive the network data from the application directly. Alternately, the application can reside on thesource210 outside of thenetwork device300. In an example, thecommunications interface330 of thenetwork device300 receives the network data from the application over thesource link380. Thecommunications interface330 then forwards the application data over thehandler link360 to thecommunications protocol handler310.

Thecommunications scheduler320 is configured to control the transmission of the packets from thecommunications protocol handler310. Thecommunications scheduler320 can determine at least one metric for a path (discussed inFIG. 2, herein) on thecommunications network240 and then control the flow of packets on that path based on the one or more metrics. The metric is any measured value related to a quality, operator, or performance of the path. In one example, the metric is a bandwidth estimate for the path. The bandwidth estimate is a value that estimates the number of packets that may be sent over a path during a predetermined time (e.g., the capacity of the path to transmit packets without congestion). If the bandwidth estimate of the path is high, the path may be capable of carrying a large number of packets. Otherwise, if the bandwidth estimate is low, the path may be capable of carrying a smaller number of packets.

Thecommunications scheduler320 can determine the bandwidth estimate of any number of paths on thecommunications network240. In one example, thecommunications scheduler320 transmits probe packets through thecommunications interface330 over thecommunications network240 to anothernetwork device300. Thecommunications scheduler320 of theother network device300 receives the probe packet and transmits a monitor packet back to the originatingnetwork device300. Thecommunications scheduler320 of the originatingnetwork device300 receives the monitor packet and determines a bandwidth estimate for the path. The determination of the metric is further discussed inFIG. 5.

Thecommunications scheduler320 can control the transmission of the packets from thecommunications protocol handler310 based on the metric of the path. In one example, thecommunications scheduler320 limits the number of packets transmitted to the capacity of the path based on the metric. This process if further discussed inFIG. 4. Although thecommunications protocol handler310 may comprise a protocol that controls the transmission of network data to avoid congestion (e.g., TCP/IP stack methodology), thecommunications scheduler320 may override this function.

By determining the capacity of the path and controlling the flow of packets over thecommunications network240, thecommunications scheduler320 can increase or optimize the speed in which network data flows across thecommunications network240. The prior art protocols typically begin at slow-start and increase speed until congestion appears. Subsequently, the prior art protocols slow down the rate of transmission and slowly increase again. Thecommunications scheduler320 can maintain speeds that the path will allow. The ultimate throughput thecommunications scheduler320 achieves may be faster than the average speed of the prior art protocols.

In some embodiments, thecommunications scheduler320 pulls packets from thecommunications protocol handler310 obviating the need for buffers. Thecommunications protocol handler310 can generate a packet at the command of thecommunications scheduler320. In one example, the speed at which packets are generated and transmitted is equivalent to the bandwidth estimate. Since thecommunications scheduler320 is pulling packets from thecommunications handler310 rather than determining transmission rates after packet generation, the packets need not be buffered before transmission. As a result, buffering may be reduced or eliminated which can increase the speed of transmission and/or reduce hardware costs.

Thecommunications interface330 is coupled to thenetwork device300, thesource210, thesource network220, and/or thecommunications network240. Thecommunications interface330 can transmit the packets received over the communications link350 from thecommunications scheduler320 to thecommunications network240. Thecommunications interface330 also provides packets received from thecommunications network240 to thecommunications protocol handler310 over thehandler link360. In some embodiments, thecommunications interface330 sends any monitor packets received from anothernetwork device300 to thecommunications scheduler320. Further, thecommunications interface330 may send any network data received from an application over the source link380 to thecommunications protocol handler310 where the network data will be subsequently organized into packets to prepare for further transmission over thecommunications network240. In some embodiments, thecommunications interface330 is linked to both thesource network220 and thecommunications network240 over a single link (e.g., thenetwork link370 or the source link380).

FIG. 4 is a flow chart for the transmission of network data in an exemplary implementation of the invention.FIG. 4 begins instep400. Instep410, the communications scheduler320 (FIG. 3) selects a path from eligible paths. An eligible path can be any path with a bandwidth estimate, a path with data to send, or any path that meets a predetermined quality of service criteria. Alternatively, the eligible path can be any path with a bandwidth estimate equal to or greater than a predetermined estimate. In another example, the eligible paths can be determined to be a predetermined percentage of paths with a higher bandwidth estimate than the others.

Thecommunications scheduler320 can select a path from the eligible paths based on the bandwidth estimate. In one example, thecommunications scheduler320 selects the path with the highest bandwidth estimate. In some embodiments, the paths may be prioritized. Specific paths may be weighed based on the properties of one or more networks within thecommunications network240. In one example, the path may extend through a virtual private network (VPN) or a network with a bandwidth guarantee.

Instep420, thecommunications scheduler320 retrieves a bandwidth estimate associated with one or more paths. Thecommunications scheduler320 can continue to retrieve or receive bandwidth estimates during any step ofFIG. 4. The process of determining a bandwidth estimate is further discussed inFIG. 5.

Instep430, thecommunications scheduler320 determines if the number of packets generated over the selected path for a predetermined time is less than the bandwidth estimate of the selected path. In one example, thecommunications scheduler320 tracks the number of packets that have been transmitted over each path as well as when the packets where transmitted. If the number of packets transmitted over the selected path during a predetermined period of time is greater than the bandwidth estimate, thecommunications scheduler320 retrieves the bandwidth estimate associated with other paths instep420. In some embodiments, thecommunications scheduler320 subsequently selects a new path from eligible paths before returning to step430. In other embodiments, if the number of packets transmitted over the selected path during a predetermined period of time is greater than the bandwidth estimate,FIG. 4 ends. If the number of packets generated for a selected path is less than the bandwidth estimate, then thecommunications scheduler320 can prioritize the data flows for the selected path instep440.

In one example, thecommunications scheduler320 queries the communications protocol handler310 (FIG. 3) for available data flows. A data flow comprises related network data or packets. In one example, packets belonging to the same data flow comprise the same source IP address, destination IP address, protocol, source port, and destination port. There may be a separate data flow for separate applications, sessions, or processes. Each data flow may also be prioritized based on the purpose of the network data within the data flow or the source of the data flow (e.g., the digital device that generated the data flow or a user of the digital device that generated the data flow). In some embodiments, thecommunications protocol handler310 notifies thecommunications scheduler320 of all data flows without being queried.

In exemplary embodiments, the data flows are weighted depending upon the application that originated the data flow, the user of the application, the number of data flows already sent from the application (or the user), and the number of packets already sent from that data flows. In one example, the data flows are all given equal weight and a packet is sent from each eligible data flow in turn (e.g., a round robin approach). In another example, certain applications or users are given priority over other applications or other users (e.g., by weighing certain applications higher than others). Packets generated by a particular source IP address or transmitted to a particular destination EP address may also be given priority. There may be many different methodologies in weighing the data flows.

Instep450, thecommunications scheduler320 selects the data flows for the selected path. In one example, the data flows are selected based on an assigned weight or priority. In some embodiments, the data flows are re-weighted (i.e., re-prioritized) after a packet is transmitted.

Instead of transmitting packets based on the round trip time of packets (e.g., the distance that packets are transmitted), packets can be transmitted based on a configurable fairness policy. A fairness policy is any policy that allows for equitable transmission of packets over the communications network. In one example, the fairness policy dictates that every data flow be given equal weight. In another example, the fairness policy dictates that certain users or data flows are more important (e.g., time sensitive) than others and therefore are given greater weight. The fairness policy can base fair transmission of packets on the saliency of users and/or data rather than the preservation of bandwidth over long distances within the communications network240 (FIG. 2).

Instep460, thecommunications scheduler320 performs a function call to thecommunications protocol handler310 to generate a packet from the selected data flow. In one example, thecommunications protocol handler310 receives network data from an application (not depicted). The network data is organized into data flows. Thecommunications scheduler320 prioritizes the data flows and selects a data flow. Subsequently, thecommunications scheduler320 provides a function call to command thecommunications protocol handler310 to organize the network data into packets.

In some embodiments, thecommunications protocol handler310 does not generate packets without a function call from thecommunications scheduler320. In one example, the packets are not buffered prior to transmission over the network link370 (FIG. 3). As a result of thecommunications scheduler320 pulling packets from thecommunications protocol handler310, buffering the packets prior to transmission may be reduced or eliminated.

Instep470, thecommunications scheduler320 transmits the packet of the selected data flow. In one example, thecommunications scheduler320 commands thecommunications interface330 to transmit the packet over thenetwork link370. Thecommunications scheduler320 then retrieves a new bandwidth estimate associated with one or more paths instep420 and the process can continue. In other embodiments,FIG. 4 ends afterstep470.

In some embodiments, thecommunications scheduler320 overrides the behavior of thecommunications protocol handler310 to transmit packets at the bandwidth estimate. In one example, thecommunications scheduler320 overrides the cwnd behavior to control the size of the congestion window of the TCP/IP stack (i.e., the communications protocol handler310). As a result, thecommunications scheduler320 can replace or modify the cwnd behavior (or any behavior that influences the congestion window) to cause thecommunications protocol handler310 to transmit packets at the rate based on the bandwidth estimate.

FIG. 5 is a flow chart for the determination of the bandwidth estimate in an exemplary implementation of the invention.FIG. 5 begins instep500. Instep510, the source network device230 (FIG. 2) generates and transmits one or more probe packets. A probe packet is a packet sent by thesource network device230 to a destination network device270 (FIG. 2) to determine a metric for a particular path. The metric may be a bandwidth estimate. In an example, the communications scheduler320 (FIG. 3) of thesource network device230 generates and subsequently transmits one or more probe packets over the communications network240 (FIG. 2). In some embodiments, the probe packets are stamped with a transmission timestamp based on the time of transmission. Further, the probe packets may be stamped with a selected path over which the probe packet is to be sent.

Instep520, thedestination network device270 receives the probe packets from thesource network device230. In an example, thecommunications scheduler320 of thedestination network device270 receives the probe packets. Thedestination network device270 marks the arrival of the one or more probe packets with a timestamp instep530. In one example, thedestination network device270 may collect probe information associated with the one or more probe packets including, but not limited to, thesource network device230 that sent the one or more probe packets, the path over which the probe packet(s) was sent, and/or the transmission timestamp of the probe packet(s).

Instep540, thedestination network device270 determines the bandwidth estimate of the selected path based on the timestamp(s) of the one or more probe packets. In some embodiments, thedestination network device270 determines the bandwidth estimate by determining the number of eligible probe packets received over a predetermined time. Eligible probe packets can be probe packets with timestamps within the predetermined time. In some embodiments, thedestination network device270 determines the bandwidth estimate based on the inter-arrival time between probe packets (e.g., the time between receipt of successive probe packets).

Instep550, thedestination network device270 generates and transmits a monitoring packet with the bandwidth estimate to thesource network device230. In one example, thecommunications scheduler320 of thedestination network device270 generates and transmits the monitoring packet to thecommunications scheduler320 of thesource network device230.

Instep560, thesource network device230 receives the monitoring packet from thedestination network device270. In some embodiments, thedestination network device270 transmits the monitoring packet over the same selected path as the one or more probe packets. Thesource network device230 can confirm the bandwidth estimate contained within the monitoring packet or modify the bandwidth estimate based on the time when the monitoring packet was received. In one example, thedestination network device270 transmits the monitoring packet with a timestamp to allow thesource network device230 to re-calculate the bandwidth estimate for the selected path. In other embodiments, thedestination network device270 transmits the monitoring packets with the timestamp over a different path to allow thesource network device230 to receive the bandwidth estimate for the selected path and calculate the bandwidth estimate for the different path.

Instep570, thesource network device230 determines the bottleneck based on the bandwidth estimate. In one example, thecommunications scheduler320 pulls packets from thecommunications protocol handler310 based on the bandwidth estimate. The pulled packets are subsequently transmitted over thecommunications network240 by thecommunications interface330.

In other embodiments, thesource network device230 transmits probe packets without timestamps to thedestination network device270 over a selected path. Thedestination network device270 receives the probe packets and transmits monitoring packets with timestamps to thesource network device230 over the same path. Thesource network device230 receives the monitoring packets and then determines the bandwidth estimate of the path based on the timestamps of the monitoring packets.

Many different probe packets may be sent over many paths from asource network device230 to many differentdestination network devices270 during a given time. By continuously discovering new paths and modifying the bandwidth estimates of existing paths, thesource network device230 can increase the through-put of packets to the destination250 (FIG. 2) without continuously decreasing and increasing the speed of packet transmission when congestion occurs.

FIG. 6 is a block diagram of anetwork device600 in an exemplary implementation of the invention. Thenetwork device600 may have a similar configuration as the source network device230 (FIG. 2) and/or the destination network device270 (FIG. 2). Thenetwork device600 includes aprocessor610, amemory620, anetwork interface630, and anoptional storage640 which are all coupled to asystem bus650. Theprocessor610 is configured to execute executable instructions.

Thememory620 is any memory configured to store data. Some examples of thememory620 are storage devices, such as RAM or ROM.

Thenetwork interface630 is coupled to thecommunications network240. (FIG. 2) and the source210 (FIG. 2) via thelink660. Thenetwork interface630 is configured to exchange communications between thesource210, thecommunications network240, and the other elements in thenetwork device600. In some embodiments, thenetwork interface630 may comprise a Local Area Network interface for thesource210 and a Wide Area Network interface for thecommunications network240.

Theoptional storage640 is any storage configured to retrieve and store data. Some examples of thestorage640 are hard drives, optical drives, and magnetic tape. Theoptional storage640 can comprise a database or other data structure configured to hold and organize data. In some embodiments, thenetwork device600 includesmemory620 in the form of RAM andstorage640 in the form of a hard drive.

The above-described functions can be comprised of executable instructions that are stored on storage media. The executable instructions can be retrieved and executed by theprocessor610. Some examples of executable instructions are software, program code, and firmware. Some examples of storage media are memory devices, tape, disks, integrated circuits, and servers. The executable instructions are operational when executed by the processor to direct the processor to operate in accord with the invention. Those skilled in the art are familiar with executable instructions, processor(s), and storage media.

FIG. 7 is an illustration of an exemplary embodiment of the operation of anetwork device300 in the prior art. Thecommunications protocol handler310 may receive application data oversource link380. In the exemplary embodiment depicted,communications protocol handler310 may be a TCP/IP stack. Thecommunications protocol handler310 may receive Packet A380A of a specified size, and forward that packet to thecommunications scheduler320, which may then place the data packet in its queue for transmission over the network.Communications protocol handler310 may then receivePacket B380B and also forward that packet to thecommunications scheduler320, which in turn may addPacket B380B to its queue for transmission over the network.Communications protocol handler310 may then receivePacket C380C and forward that packet to thecommunications scheduler320, which in turn may addPacket C380C to its queue for transmission over the network. Thus,communications scheduler320 may have three separate data packets in its queue for transmission over the network.

FIG. 8 is an illustration of an exemplary embodiment of the operation of anetwork device300 according to the present invention. Thecommunications protocol handler310 may receive application data oversource link380. In the exemplary embodiment depicted,communications protocol handler310 be a TCP/IP stack. The TCP/IP stack may receive Packet A380A of a specified size, which is then kept by the TCP/IP stack.Communications protocol handler310 may then receivePacket B380B, which is also added to the data held at the TCP/IP stack.Communications protocol handler310 may then receivePacket C380C, which is subsequently added to the data held at the TCP/IP stack. Thecommunications scheduler320 may then be informed that the TCP/IP stack has data to be transmitted. As discussed herein, thecommunications scheduler320 may select a suitable path and prioritize data flows for the selected path. Thecommunications scheduler320 may then direct the TCP/IP stack to generate one or more data packets for the data flow to be transmitted over the network. In an exemplary embodiment, thecommunications protocol handler310 may then generatePacket D380D, containing the data from Packets A, B, and C, and send that packet to thecommunications scheduler320, which may in turn direct it to thecommunications interface330 for transmission over the network.Packet D380D may be a single data packet or multiple data packets.

The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those of skill in the art upon review of this disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the appended claims along with their full scope of equivalents.

Claims (15)

What is claimed is:

1. A system for providing network communications, the system comprising:

a TCP/IP stack module stored in memory and executed by a processor to:

receive application data in a data flow, inform a communications scheduler module that the data flow has data to be transmitted over a network, and generate at least one data packet for the data flow from the application data to be transmitted over the network, when directed by the communications scheduler module;

the communications scheduler module stored in memory and executed by the processor to:

determine the capacity of a path, select a suitable path, prioritize data flows for the selected path based on the TCP/IP stack module informing the communications scheduler module which data flows have data to be transmitted, select a data flow for the selected path, and direct the TCP/IP stack module to generate the at least one data packet for the data flow from the application data in the selected data flow, buffering of the at least one data packet from the application data not being required at the communications scheduler module; and

a communications interface module stored in memory and executed by the processor to transmit the at least one data packet for the data flow via the selected path at an optimal transmission rate, wherein the data flow is transmitted over the selected path without waiting for lost packets or acknowledgements to indicate network congestion.

2. The system ofclaim 1, wherein the execution of the communications scheduler module to determine the capacity of the path includes determining a bandwidth estimate.

3. The system ofclaim 1, the communications scheduler module is executable to determine whether a data flow has information to send prior to selecting the data flow for the path.

4. The system ofclaim 1, wherein the communications scheduler module is executable to determine respective priorities of data flows and select the data flow based on the priorities and the capacity of the path.

5. The system ofclaim 4, wherein the priorities are based on a fairness policy.

6. A method for providing network communications, the method comprising:

executing by a processor a TCP/IP stack module stored in memory to:

receive application data in a data flow, inform a communications scheduler module that the data flow has data to be transmitted over a network, and generate at least one data packet for the data flow from the application data to be transmitted over the network, when directed by the communications scheduler module;

executing by a processor the communications scheduler module stored in memory to:

determine the capacity of a path, select a suitable path, prioritize data flows for the selected path based on the TCP/IP stack module informing the communications scheduler module which data flows have data to be transmitted, select a data flow for the selected path, and direct the TCP/IP stack module to generate the at least one data packet for the data flow from the application data in the selected data flow, buffering of the at least one data packet from the application data not being required at the communications scheduler module; and

executing by a processor a communications interface module stored in memory to transmit the at least one data packet for data flow via the selected path at an optimal transmission rate, wherein the data flow is transmitted over the selected path without waiting for lost packets or acknowledgements to indicate network congestion.

7. The method ofclaim 6, wherein executing the communications scheduler module to determine the capacity of the path includes determining a bandwidth estimate.

8. The method ofclaim 6, further comprising executing the communications scheduler module to determine whether a data flow has information to send prior to selecting the data flow for the path.

9. The method ofclaim 6, further comprising executing the communications scheduler module to determine respective priorities of data flows, wherein the data flow is selected based on the priorities and the capacity of the path.

10. The method ofclaim 9, wherein the priorities are based on a fairness policy.

11. A non-transitory computer readable storage medium having a program embodied thereon, the program executable by a processor to perform a method for providing network communications, the method comprising:

executing a TCP/IP stack module stored in memory to:

receive application data in a data flow, inform a communications scheduler module that the data flow has data to be transmitted over a network, and generate at least one data packet for the data flow from the application data to be transmitted over the network, when directed by the communications scheduler module;

executing the communications scheduler module stored in memory to:

determine the capacity of a path, select a suitable path, prioritize data flows for the selected path based on the TCP/IP stack module informing the communications scheduler module which data flows have data to be transmitted, select a data flow for the selected path, and direct the TCP/IP stack module to generate the at least one data packet for the data flow from the application data in the selected flow, buffering of the at least one data packet from the application data not being required at the communications scheduler module; and

executing a communications interface module stored in memory to transmit the at least one data packet for data flow via the selected path at an optimal transmission rate, wherein the data flow is transmitted over the selected path without waiting for lost packets or acknowledgements to indicate network congestion.

12. The computer readable storage medium ofclaim 11, wherein executing the communications scheduler module to determine the capacity of the path includes determining a bandwidth estimate.

13. The computer readable storage medium ofclaim 11, wherein the method further comprises executing the communications scheduler module to determine whether a data flow has information to send prior to the selection of the data flow for the path.

14. The computer readable storage medium ofclaim 11, wherein the method further comprises executing the communications scheduler module to determine respective priorities of data flows, wherein the data flow is selected based on the priorities and the capacity of the path.

15. The computer readable storage medium ofclaim 14, wherein the priorities are based on a fairness policy.

Images