Abstract:
Aggregation windows are dynamically resized based on network congestion feedback from VOIP and other mixed types of traffic. Feedback indicative of a level of network congestion on the data communication network where aggregate packets are transmitted is received. The network congestion level is checked to see if a predetermined threshold has been exceeded. Responsive to exceeding the threshold, the network congestion level is correlated to an optimal data field size for the aggregated data packets. Further, a MAC layer is configured for the optimal data field size for frame generation. Subsequent aggregated data packets are then transmitted using the optimal data field size.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims the benefit of priority to U.S. Application Nos. 62/098,317, filed Dec. 30, 2014, entitled DYNAMICALLY RESIZING AGGREGATION WINDOWS BASED ON NETWORK CONGESTION FROM MIXED TYPES OF TRAFFIC IN A WIRELESS NETWORK, by Manish SHUKLA, et al. and 62/099,126, filed Dec. 31, 2014, entitled SELF-PROVISIONING IN WI-FI NETWORKING WITH SDN (SOFTWARE-DEFINED NETWORKING) CONTROLLERS USING PREDICTIVE TRAFFIC LOADS IN A WIRELESS COMMUNICATION NETWORK, by Anil KAUSHIK, the contents of each being hereby incorporated by reference in their entirety. 
     
    
     FIELD OF THE INVENTION 
       [0002]    The invention relates generally to computer networking, and more specifically, to dynamically resizing aggregation windows based on network congestion from VOIP and other mixed types of traffic. 
       BACKGROUND 
       [0003]    Audio and video consumption on the Internet continues to rise from a baseline of mainly text consumption. Additional bandwidth and speed in the backbone networks, along with price decreases in consumer storage, supports consumer appetites for the richer experience gleaned from audio and video. For example, new protocols such as IEEE 802.11ac provide aggregated packets with large data fields for combining several different packets into a single aggregated packet. Under IEE 802.11ac, every packet is typically an aggregated packet, regardless of content. 
         [0004]    Problematically, the rising popularity of VOIP traffic strains network efficiency in a different way. Namely, VOIP traffic can operate on lower data rates (e.g., 54 Mb/s) which keep the channel busy for relatively longer periods of time when filling up the large data fields of aggregated packets. Consequentially, as VOIP traffic increases on a channel using aggregated packets, so do does the collision rate and network congestion. 
         [0005]    What is needed is a robust technique to dynamically resize aggregation windows based on network congestion from VOIP traffic or other compositions of traffic. 
       SUMMARY 
       [0006]    The shortcomings of the prior art are addressed by methods, (non-transitory) computer program products, and systems for dynamically resizing aggregation windows based on network congestion feedback from VOIP and other mixed types of traffic, as described herein. 
         [0007]    In one embodiment, aggregated data packets are transmitted. Feedback indicative of a level of network congestion on the data communication network is received. The network congestion level is checked to see if a predetermined threshold has been exceeded. 
         [0008]    Responsive to exceeding the threshold (or alternatively whether or not threshold is exceeded), the network congestion level is correlated to an optimal data field size for the aggregated data packets. Further, a MAC layer is configured for the optimal data field size for frame generation. Subsequent aggregated data packets are then transmitted using the optimal data field size. 
         [0009]    Advantageously, computer performance is enhanced because network congestion caused by VOIP applications over IEEE 802.11ac is reduced. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0010]    In the following drawings, like reference numbers are used to refer to like elements. Although the following figures depict various examples of the invention, the invention is not limited to the examples depicted in the figures. 
           [0011]      FIG. 1  is a high-level block diagram illustrating a system to dynamically resize aggregation windows, according to one embodiment. 
           [0012]      FIG. 2  is a more detailed block diagram illustrating a congestion module of  FIG. 1 , according to one embodiment. 
           [0013]      FIG. 3  is a block diagrams illustrating aggregated packet formats, according to one embodiment. 
           [0014]      FIG. 4  is a block diagram illustrating a method for optimally sizing aggregate packets based, according to one embodiment. 
           [0015]      FIG. 5  is a more detailed block diagram illustrating a step for dynamically resizing aggregation windows based on network congestion feedback of  FIG. 4 , according to one embodiment. 
           [0016]      FIG. 6  is a block diagram illustrating an exemplary computing device, according to one embodiment. 
       
    
    
     DETAILED DESCRIPTION 
       [0017]    Methods, (non-transitory) computer program products, and systems for dynamically resizing aggregation windows based on network congestion feedback from VOIP and other mixed types of traffic, as described herein. Generally, one of ordinary skill in the art will recognize that the examples set forth herein are non-limiting and only illustrative of widely-applicable principles. For example, although VOIP traffic over IEEE 802.11ac is referred to throughout the description, one of ordinary skill in the art with recognize how the general principles can be applied to many different circumstances. For example, these techniques can be applied to other types of traffic that affect congestion and to other protocols using resizable aggregated data packets. Further, these techniques can be applied to channels other than Wi-Fi, such as Bluetooth or wired networks. 
       I. Systems to Dynamically Resize Aggregation Windows (FIGS.  1 - 3 ) 
       [0018]      FIG. 1  is a high-level block diagram illustrating a system  100  to dynamically resize aggregation windows, according to one embodiment. The system  100  includes, a congestion module  110 , a Wi-Fi controller  120 , an SDN (software-defined network controller)  130 , access points  140 A- 140 B, and stations  150 A- 150 C. The components can be implemented in hardware, software, or a combination. The system  100  is merely an example of many possible configurations which could include more or less access points, controllers, stations, and can also include well known components such as routers, switches, and firewalls. 
         [0019]    A network  199  couples the components in communication for data transfers in the form of frames. Some components are preferably wired to the network  199  (e.g., congestion module  110 , Wi-Fi controller  120 , SDN controller  130  and access points  140 A- 140 B. The stations  150 A- 150 C are wireless connected to the access points  140 A-B on a Wi-Fi network portion. The network  199  can be a LAN, WAN, the Internet, a cloud-based network, a data network, a cellular network, a hybrid network, or the like. The system  100  is merely an example of many possible configurations which could include more or less access points, controllers, stations, and can also include well known components such as routers, switches, and firewalls. 
         [0020]    The congestion module  110  responds to network feedback by adjusting the size of aggregated packets (e.g., a variable-sized data field). In one embodiment, network feedback is based on measurements of VOIP traffic relative to other types of traffic to proactively prevent potential collisions from increasing VOIP traffic composition. In another embodiment, network feedback is based on measurements of network congestion resulting from VOIP traffic relative to other types of traffic to adjust to actual collisions resulting from VOIP traffic composition. Measurements can be made from a local perspective or a network-wide perspective. An alternative embodiment switches just VOIP packets to a protocol that does not use aggregated frames. 
         [0021]    The congestion module  110  can be integrated with the Wi-Fi controller  120  at an operating system level or installed as an application. Alternatively, the congestion module  110  can be partially or fully integrated with the SDN controller  130 , the access points  140 A- 140 B, or the stations  150 A- 150 C. In still other embodiments, the congestion module  130  can be implemented in a dedicated device, or be a cloud-based service provided by a third party. Combinations of implementations are also possible. Further embodiments of the congestion module  110  are discussed below with reference to  FIG. 2 . 
         [0022]    The Wi-Fi controller  120  manages window resizing from a network-side perspective. Measurements of a congestion index or VOIP traffic congestion can be taken from different points around a network to get a better context on overall traffic moving through the backbone. Resulting direction to the access points  140 A- 140 B can provide a packet size for use by all access points, or just a baseline that can be locally modified by local conditions of access points. 
         [0023]    The Wi-Fi controller  120  (e.g., an MC1500 or MC6000 device by Meru Networks/Fortinet, Inc. of Sunnyvale, Calif. as described in U.S. application Ser. No. 13/426,703 filed Mar. 22, 2012, now issued U.S. Pat. No. 9,215,754 and commonly-assigned) provides centralized management for the access points  140 A- 140 B. The Wi-Fi controller  120  can provide many other services to the network  199  such as virtual cell and virtual port functionalities (see further description in U.S. application Ser. No. 13/426,703, which is hereby incorporated by reference). In some embodiments, the Wi-Fi controller  120  can be a cloud-based Wi-Fi controller that provides management and monitoring services to the system  100 . 
         [0024]    The SDN controller  130 , in an embodiment, detects VOIP applications and sends configuration instructions. The SDN controller  130  can also indirectly cooperate by predicting network congestion as discussed more fully in U.S. Application No. 62/099,126, filed Dec. 31, 2014. Other indirect actions may affect packet sizes using the OpenFlow or other protocol to directly implement layer 2 rules. More specifically, the SDN controller  130  directs the access points  140 A- 140 B to drop VOIP packets using data plane rules (e.g., OpenFlow rules or any rules to directly affect routing decisions), in an embodiment, which in turn can result in smaller packet sizes being sent by VOIP applications. OpenFlow provides cross-vendor communication as an abstraction of vendor-specific internal programming. Deep packet inspection permits the SDN controller  130  to identify different types of traffic. 
         [0025]    More generally, the SDN controller  130  centralizes data plane decision-making for the access points  140 A- 140 B. To do so, the access points  140 A-B are configured to concede layer 2 routing decisions to the SDN controller  130  by forwarding packets to the SDN controller  130  for routing instructions. The SDN controller  130  can use input gathered across the network to make layer 2 routing decisions for the packets which are communicated back to the forwarding one of the access points  140 A- 140 B. In one embodiment, routing decisions are made as a reaction to new or unknown flows. In another embodiment, access points are pre-configured by the SDN controller  130  with rules for automatically implementing SDN controller  130  decisions on matching packets in the future. In still another embodiment, the rules or policies are distributed to the other network devices along a routing path for multi-hop data plane control. 
         [0026]    The SDN controller  130  can be, for example, a personal computer, a laptop computer, a server, a cloud-based device, a virtual device, or the like implemented in any of the computing devices discussed herein. 
         [0027]    The access points  140 A- 140 B implement packet resizing as directed by any or a combination of the congestion module  110 , the Wi-Fi controller  120  and the SDN controller  130 . More specifically, the access points  140 A- 140 B can react to network congestion or traffic composition by changing a data field size at the MAC layer. In some embodiments, the access points  140 A- 140 B react dynamically in real-time to information fed back. 
         [0028]    In general, the access points  140 A- 140 B can individually represent one or more computing devices. For example, the access points  140 A- 140 B can be an AP  110  or AP  433  (modified as discussed herein) by Meru Networks/Fortinet, Inc. of Sunnyvale, Calif. Each access point  140 A- 140 B is preferably connected to the network  199  (e.g., gateway, switch, router, hub, or another access point that is connected to the network  199 ) via a wired connection, but in some embodiments, such as a mesh network, the uplink connection is wireless. The access points  140 A- 140 B can be set-up in various configurations to provide wireless coverage areas. In another embodiment, the functionality is incorporated into a switch or router. 
         [0029]    The stations  150 A- 150 C devices accessed by a user or running a program such as a VOIP application or a video application. Examples of VOIP applications include IP-based home telephones, Google Voice, Skype telephone calls, and the like. The VOIP applications can be installed on the stations  150 A- 150 C or execute remotely using a browser, for example. A VOIP application can also be executing on a device accessing one of the stations  150 A- 150 C as a hot spot. 
         [0030]    More generally, the stations  150 A- 150 C can be, for example, a personal computer, a laptop computer, a tablet computer, a smart phone, a mobile computing device, an Internet appliance, a non-wireless device modified to have wireless capabilities, or any other appropriate processor-driven computing device. A station is wirelessly coupled to an access point. No pre-configuration or client is needed, in an embodiment. 
         [0031]      FIG. 2  is a more detailed block diagram illustrating the congestion module  110  of  FIG. 1 , according to one embodiment. The congestion module  110  comprises a congestion feedback module  210 , a packet size correlator  220 , a packet generator  230  and a packet queue  240 . Other embodiments are possible. 
         [0032]    The congestion feedback module  210  provides data on actual or predicted network congestion. In one case, actual congestion data is measured locally, such as downstream from a particular access point. In another case, actual congestion data is measured network-wide by one or more sensors or by the Wi-Fi controller  120  or by the SDN controller  130 . Congestion data can be limited to only VOIP traffic (e.g., a gross amount of VOIP traffic, or a ratio of VOIP traffic relative to other types), or can include all types of traffic. Measurements can be taken periodically or on demand. In one embodiment, network congestion is predicted based on implementation-specific factors such as network congestion history, a change in a number of connected devices, or planned events. Predictions can be taken alone as a measurement, or in combination with actual measurements. Upstream devices such the Wi-Fi controller  120  and the SDN controller  130  can also provide values for congestion measurement that are implemented at an access point. 
         [0033]    The packet size correlator  220  identifies an optimal packet size based on network congestion feedback. In an embodiment, a table of values is prepopulated and network congestion feedback or a derivate thereof is utilized an index into the table. In another embodiment, packet sizes are provided by upstream devices or by peer devices. 
         [0034]    The packet generator  230  composes data packets at a MAC layer responsive to the optimal packet size. The maximum length of an A-MPDU field is controlled by the value of a filed called Maximum A-MPDU Length Exponent, which describes maximum length of an A-MPDU by the formula 2̂ (13+Exponent)-1 bytes. Under IEE 802.11ac, values for the exponent range from 0 to 7 which allow the maximum-MPDU length to range from 8 KB to 1 MB. The resulting packets can be stored in the packet queue  240  until further processed or transmitted. For frame aggregation, the packet generator  230  can look ahead in the packet queue  240  to find frames for coalescing into a single aggregate frame. In one example, just VOIP data packets can be aggregated while others are sent using standard aggregated data packets. The IEEE 802.11ac protocol transmits all frames using an aggregate MPDU (A-MPDU) format, even for single frames. The MAC layer controls framing responsibility, leaving the physical layer with just the total length of what it transports. One embodiment of the packet generator  230  uses a non-aggregating protocol for VOIP packets, and can use a different radio or communication channel. 
         [0035]      FIG. 3  is a block diagram illustrating aggregated packet formats  300 , according to one embodiment. An initial IEEE 802.11 packet  101  includes a TCP (or UDP) packet  302  along with a (physical layer) header  301 . The TCP packet  302  can hold up to 1,300 bytes in some embodiments. The TCP packet  302  can include a TCP header (not shown) with fields for frame control, duration/ID, address, sequence control, and the like. The frame control field can include fields for protocol version, type, subtype, to DS, from DS, more fragments, retry, power management, WEP, order, and the like. Additionally, an FCS  303  (Frame Check Sequence) ensures data integrity. 
         [0036]    An A-MSDU  392  frame can include a data as MSDU sub-frames  304 A,  304 B and header data. The data packet was increased to nearly 8 k under IEEE 802.11n and 802.11ac. The header data can include fields for a destination address  311 , source address  312 , length  313  and padding  315 . 
         [0037]    An A-MPDU frame  391  includes MPDU sub-frames  303 A,  303 B and header data. The A-MPDU frame  391  can be hold up to 1 Mb under the IEEE 802.11ac standard. Under the technique described herein,  64  packets of up to 8 k bytes accounts for about 480 kb, well within the limit. Other fields can include reserved  321 , MPDU length  322 , CRC  323 , delimiter signature  324  and padding  326 . MPDU. 
         [0038]    Finally, an IEEE 802.11 high throughput packet with A-MPDU and A-MSDU frames  130  is composed of a (A-MPDU PHY) header  301 , a A-MPDU frame  491  and an FCS  303 , similar to IEEE 802.11 network packet  101 . However, the TCP packet  302  has been replaced with the A-MPDU frame  491  and any supporting data needed. In symbolic form, IEEE802.11 High Throughput Packet={header, A-MPDU} where A-MPDU={A-MSDU 1 , A-MSDU 2  . . . , A-MSDUn} where A-MSDU(i)={{DA, SA, TCP Packet 1 , Padding}, {DA, SA, TCP Packet 2 , Padding}, . . . {{DA, SA, TCP Packetn, Padding}}. MPDU. 
       II. Methods for Dynamically Resizing Aggregation Windows (FIGS.  4 - 5 ) 
       [0039]      FIG. 4  is a block diagram illustrating a method for optimally sizing aggregate packets based, according to one embodiment. One of ordinary skill in the art will recognize that the method  400  is non-limiting as other embodiments can have more or less steps and can be performed in a different order. 
         [0040]    Packets are transmitted from Wi-Fi devices using IEEE 802.11ac aggregated packets (step  410 ). Aggregation windows are dynamically resized based on network congestion feedback (step  420 ), as is described in more detail below with respect to  FIG. 5 . Subsequent packets are transmitted from the Wi-Fi device using optimal data field size (step  430 ). 
         [0041]      FIG. 5  is a more detailed block diagram illustrating the step  430  for dynamically resizing aggregation windows based on network congestion feedback of  FIG. 4 , according to one embodiment. 
         [0042]    A congestion index can be determined by measuring network congestion (step  510 ). Alternatively, an amount of VOIP traffic can be measured as an indicator of potential network congestion. When a congestion index threshold is met (step  520 ), the congestion index is correlated to an optimal data field size for aggregate packets (step  530 ). MAC layer packets are configured for a new data field size, according to IEEE 802.11ac or other protocols (step  540 ). 
       III. Generic Computing Device (FIG.  6 ) 
       [0043]      FIG. 6  is a block diagram illustrating an exemplary computing device  600  for use in the system  100  of  FIG. 1 , according to one embodiment. The computing device  600  is an exemplary device that is implementable for each of the components of the system  100 , including the congestion module  110 , the Wi-Fi controller  120 , the SDN controller  130 , the access points  140 A,  140 B, and the stations  150 A- 150 C. The computing device  600  can be a mobile computing device, a laptop device, a smartphone, a tablet device, a phablet device, a video game console, a personal computing device, a stationary computing device, a server blade, an Internet appliance, a virtual computing device, a distributed computing device, a cloud-based computing device, or any appropriate processor-driven device. 
         [0044]    The computing device  600 , of the present embodiment, includes a memory  610 , a processor  620 , a storage drive  630 , and an I/O port  640 . Each of the components is coupled for electronic communication via a bus  699 . Communication can be digital and/or analog, and use any suitable protocol. 
         [0045]    The memory  610  further comprises network applications  612  and an operating system  614 . The network applications  612  can include the modules of the components illustrated in  FIGS. 1 . Other network applications  612  can include a web browser, a mobile application, an application that uses networking, a remote application executing locally, a network protocol application, a network management application, a network routing application, or the like. 
         [0046]    The operating system  614  can be one of the Microsoft Windows® family of operating systems (e.g., Windows 65, 68, Me, Windows NT, Windows 2000, Windows XP, Windows XP x64 Edition, Windows Vista, Windows CE, Windows Mobile, Windows 6 or Windows 8), Linux, HP-UX, UNIX, Sun OS, Solaris, Mac OS X, Alpha OS, AIX, IRIX32, or IRIX64. Other operating systems may be used. Microsoft Windows is a trademark of Microsoft Corporation. 
         [0047]    The processor  620  can be a network processor (e.g., optimized for IEEE 802.11), a general purpose processor, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a reduced instruction set controller (RISC) processor, an integrated circuit, or the like. Qualcomm Atheros, Broadcom Corporation, and Marvell Semiconductors manufacture processors that are optimized for IEEE 802.11 devices. The processor  620  can be single core, multiple core, or include more than one processing elements. The processor  620  can be disposed on silicon or any other suitable material. The processor  620  can receive and execute instructions and data stored in the memory  610  or the storage drive  630   
         [0048]    The storage drive  630  can be any non-volatile type of storage such as a magnetic disc, EEPROM, Flash, or the like. The storage drive  630  stores code and data for applications. 
         [0049]    The I/O port  640  further comprises a user interface  642  and a network interface  644 . The user interface  642  can output to a display device and receive input from, for example, a keyboard. The network interface  644  (e.g. RF antennae) connects to a medium such as Ethernet or Wi-Fi for data input and output. 
         [0050]    Many of the functionalities described herein can be implemented with computer software, computer hardware, or a combination. 
         [0051]    Computer software products (e.g., non-transitory computer products storing source code) may be written in any of various suitable programming languages, such as C, C++, C#, Oracle® Java, JavaScript, PHP, Python, Perl, Ruby, AJAX, and Adobe® Flash®. The computer software product may be an independent application with data input and data display modules. Alternatively, the computer software products may be classes that are instantiated as distributed objects. The computer software products may also be component software such as Java Beans (from Sun Microsystems) or Enterprise Java Beans (EJB from Sun Microsystems). 
         [0052]    Furthermore, the computer that is running the previously mentioned computer software may be connected to a network and may interface to other computers using this network. The network may be on an intranet or the Internet, among others. The network may be a wired network (e.g., using copper), telephone network, packet network, an optical network (e.g., using optical fiber), or a wireless network, or any combination of these. For example, data and other information may be passed between the computer and components (or steps) of a system of the invention using a wireless network using a protocol such as Wi-Fi (IEEE standards 802.11, 802.11a, 802.11b, 802.11e, 802.11g, 802.11i, 802.11n, and 802.11ac, just to name a few examples). For example, signals from a computer may be transferred, at least in part, wirelessly to components or other computers. 
         [0053]    In an embodiment, with a Web browser executing on a computer workstation system, a user accesses a system on the World Wide Web (WWW) through a network such as the Internet. The Web browser is used to download web pages or other content in various formats including HTML, XML, text, PDF, and postscript, and may be used to upload information to other parts of the system. The Web browser may use uniform resource identifiers (URLs) to identify resources on the Web and hypertext transfer protocol (HTTP) in transferring files on the Web. 
       IV. Additional Embodiments 
       [0054]    Generally, one of ordinary skill in the art will recognize that the examples set forth herein are non-limiting and only illustrative of widely-applicable principles. Accordingly, this description of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form described, and many modifications and variations are possible in light of the teaching above. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications. This description will enable others skilled in the art to best utilize and practice the invention in various embodiments and with various modifications as are suited to a particular use. The scope of the invention is defined by the following claims.