WinTC Version : 0.2.9c About WinTC ----------- WinTC is a program that can set upper limit on upstream bandwidth for non-QoS applications (bandwidth control) or can prioritize network traffic for certain applications (priority control). The program utilizes Windows QoS Packet Scheduler component that was added in Windows 2000. Note that WinTC can only enforce bandwidth usage / priority on network packets that are transmitted from the PC that WinTC is running on. Problem ------- ADSL and many CATV internet connections are asymmetric in the sense that upstream speed is much slower than downstream speed. examples downstream upstream a slow ADSL 1.5Mbit/s 128kbit/s (~12KB/sec) a CATV 1.5Mbit/s 256kbit/s (~25KB/sec) an 8MB ADSL 8Mbit/s 1Mbit/s (~100KB/sec) Applications that utilize upstream bandwidth 1) sending emails 2) uploading to web servers 3) file sharing via Web/FTP servers 4) uploading by P2P/IM programs When your home servers and/or P2P/IM programs use up most of available upstream bandwidth, other more important applications are left with very small amount of bandwidth. Solution -------- Enforce upper limit on upstream bandwidth that your servers use. For example, out of total 100KB/sec upstream bandwidth, allocate only 30KB/sec for servers and 20KB/sec for P2P uploads. Then the remaining 50KB/sec bandwidth can be reserved for more important applications (email sending and web uploads, etc). Or, instead of placing upper limit on less important applications, give priority to the bandwidth that your important applications require. For example, give high priority 50KB/sec bandwidth to email sending and web uploads. Then other less important applications can use whatever is left behind by important applications. Note that 50KB/sec bandwidth will not be reserved and left unused for applications that are not running. System Requirements ------------------- - Microsoft Windows XP - Microsoft Windows 2000 (SP3 recommended) - Microsoft Windows 2003 Upgrade Notes ------------- 0.2.8 : Re-create "wintc" service Please remove the existing "wintc" service you created with rbp.exe. Then create new "wintc" service with wintc.exe that comes with 0.2.8 or later. >cd >rbp -kd wintc >wintc -kc If you need to specify another name for the service, do "wintc -kc ". Install ------- - Unpack wintc.zip into a directory. Files included: rbp.exe - NT service program that will host WinTC module rbp.conf - config file for rbp (you don't need to edit this file) wintc.exe - command line tool for WinTC wintc.conf, wintc_cl.conf - sample configuration files - Install QoS Packet Scheduler for the network interface on which you want to control bandwidth. Note that QoS Packet Scheduler is a part of Windows OS, not part of WinTC package. WinXP: QoS Packet Scheduler should be already installed on ordinary physical network interfaces. Win2000: Open "Property" of your network interface and click "Install". Choose "QoS Packet Scheduler" from "Service" category. Win2003: Open "Property" of your network interface and click "Install". Choose "QoS Packet Scheduler" from "Service" category. - Run wintc.exe to install as a NT service with the name "wintc". rbp.exe is the NT service that will host WinTC module. >wintc -kc If you need to specify another name for the service, do "wintc -kc ". - Edit configuration file (wintc.conf) as described in the next section. Then start "wintc" service: >net start wintc - any error or informational messages will be written to event.log file. Configuration ------------- Flow : A flow is a single virtual upstream pipe that is to be associated with a network interface. A flow has several bandwidth- related attributes, including packet transmit rate and priority. Filter : You can think of a filter as a set of particular services that you define with several TCP/IP attributes like source/destination ports, source/destination IP addresses, and protocols (TCP,UDP,ICMP). An example is an HTTP service running on TCP port 80. Another example is an SMB service that is servicing to particular set of computers on the LAN. Assign : You will control outgoing traffic bandwidth by deciding which services (i.e. filters that you defined) can use which flow. This is called assinging filters to a flow. Defining a flow define_flow = : name you give to the flow : bandwidth (transmit rate (bytes/second)) : optional attributes of flow (separated by whitespace) prio= : priority (1=high,2=medium,3=standard) default is 2 limit={yes|discard|no} : default is "yes". if yes or discard, bandwidth upper limit is enforced. if no, only packet prioritization is done and this flow is allowed to use more bandwidth than specified in as long as there are extra bandwidth left on the NIC. TokenBucketSize, PeakBandwidth : advanced mode parameters See "TC API" section in this document for details. ex. define_flow = flow-test-1 30K prio=2 Defining a filter define_filter = : name you give to the filter : optional attributes of filter (separated by whitespace) srcport=[/] : source port range dstport=[/] : dest port range is 16bit mask srcaddr=[/] : source addr range dstaddr=[/] : dest addr range is 32bit mask proto= tcp or udp. default is tcp. or, a decimal number (see IPPROTO_XXX in MSSDK/include/WinSock2.h) ex.1 define_filter = filt-http srcport=80 define_filter = filt-https srcport=443 You cannot specify arbitrary ranges for ports and IP addresses. You can only use bitmasks to specify ranges. Bitmask for a port range is 16bits, IP address 32bits. If unspecified, /16 and /32 are assumed for ports and addresses respectively. For port ranges, you can run "wintc -u " to list all port ranages available with that mask. ex.2 - port range define_filter = filt-ftp-data-pasv srcport=0x2000/4 # source port range from 0x2000 to 0x2fff (from 8192 to 12287) ex.3 - address range define_filter = filt-internal dstaddr=192.168.100.0/24 # destination address range from 192.168.100.0 to 19.168.100.255 Assining filters to flow assign_filter = : name of filter to assign (multiple filters will be supported in future) : name of flow ex. assign_filter = filt-http flow-test-1 assign_filter = filt-https flow-test-1 Restrictions in configuration Due to QoS Packet Scheduler's limitations, there are resrictions in configuration. - If you define any filter for server use, you can not define any filter for client use. The opposite is also true. Specifically, you cannot define the following: define_filter = sv-http srcport=80 define_filter = cl-https dstport=443 This is because the ranges that two filters define are overlapping. sv-http : srcport=80 dstport=* srcaddr=* dstaddr=* cl-https : srcport=* dstport=443 srcaddr=* dstaddr=* If a packet with srcport=80, dstport=443 ever comes to Packet Scheduler, it cannot determine which filter to apply to the packet. I believe that it is the reason that Packet Scheduler rejects such overlapping filters. Therefore, you have to choose between two configuration styles, one for limtting server-use bandwidth and the other for prioritizing important client traffic. P2P and IM traffic use TCP/UDP connections in very dynamic ways, so they cannot be categorized as either. See Overlapping Filters section for more details on this. Specifying a particular NIC in presence of multiple NICs run "wintc -i" to list all NICs with Packet Scheduler enabled. Specify either of the following: a) Specify the interface number displayed in the following configuration parameter: default_netif = 1 b) Specify the interface name as displayed on "wintc -i" in the following configuration parameter (do not include double quotes): default_netif_name = Intel(R) PRO/100 VE Network Connection - Packet Scheduler Miniport Sample configuration files -------------------------- Two samples are provided. Although they strive to give sufficient bandwidth to important clients like email sending and web uploads, they employ different policies towards implementation. 1) Control bandwidth for servers filename: wintc.conf By limitting outbound bandwidth for HTTP/FTP server programs, you will reserve a certain amount of bandwidth for other important applications. srcport=80 (HTTP server) srcport=443 (HTTPS server) srcport=20 (FTP data - port mode) srcport=16384-16639 (FTP data - pasv mode - adjust to your FTP setup) 2) Prioritize bandwidth for important client applications filename: wintc_cl.conf Give high priority to network traffic for these applications. By setting uppper limit to the full capacity of the physical line, these applications are able to use all network bandwidth whenever they need, while letting other low priority applications use remaining bandwidth. dstport=80 (HTTP upload) dstport=443 (HTTPS upload) dstport=25 (SMTP send) Note that you cannot define bandwidth for FTP data connections. More Advanced Configurations ---------------------------- 3) LAN PC Give priority to remote PC control applications (RDP and VNC). srcport=3389 (RDP server - PC running Remote Desktop Server) srcport=5900 (VNC server - this will vary in your env) 4) Limit ALL application's upstream bandwidth use on a particular PC Let's say you have a child who are using up all upstream bandwidth with his P2P/IM upload! You want to limit ALL of his applications' upstream bandwidth to a fixed limit, say 20KB/sec, with "approved" applications excepted. In this case, you install wintc onto each the PC(s) you want to put limit on, then configure wintc on each PC. First you put the cap on all applications/ports (catch-all filter), then add "exception" filters for applications/ports as necessary either as server-type or client type. This example uses overlapping filters but is possible because the ranges are proper subset of the catch-all filter. # cap for all ports / all IP addresses srcport=0/0 # "approved" applications dstport=80 (HTTP upload) dstport=443 (HTTPS upload) dstport=25 (SMTP upload) 5) Limit upload bandwidth from all client PCs on the gateway server You have a Windows PC/server with two NICs that acts as the gateway (router) to the Internet. There are three client PCs connected to the inner NIC and you want limit upload bandwidth used by two of the client PCs. Note that packet forwarding between the two NICs must be enabled at the OS level on the gateway PC/server. That is, if you disable the packet forwarding and you only have an application level gateway/proxy software to handle packet forwarding, WinTC bandwidth control will not be effective. external NIC (outgoing): IP address: internal NIC : IP address: 192.168.1.1 Client-1: 192.168.1.100 statically assigned ("Bandwidth Exempt") Client-2: 192.168.1.101 assigned by internal DHCP Client-3: 192.168.1.102 assigned by internal DHCP Filters exempt: srcaddr=192.168.1.100 capped: srcaddr=192.168.1.0/24 Flows flow-10KB: 10KBytes/sec flow-nolim: no limit Assign filters to the flow Filter "capped" will use "flow-10KB". --- wintc.conf --- # put limits on outgoing NIC default_netif = 1 define_flow = flow-10KB 10K define_flow = flow-nolim 1000K limit=no define_filter = capped srcaddr=192.168.1.0/24 define_filter = exempt srcaddr=192.168.1.100 assign_filter = capped flow-10KB assign_filter = exempt flow-nolim --- end --- Start ----- To start WinTC as an NT service, run: >net start wintc Traffic control that is set by WinTC is in effect as long as this program stays alive. To terminate wintc, run "net stop wintc". To dump Packet Scheduler's information that is currently defined on the OS, do: >wintc -i -v What is "reservable bandwidth"? ------------------------------- Reservable bandwidth for a NIC is the bandwidth pool from which WinTC allocates bandwidth for each flow whose priority is either 1(high) or 2(medium). The value of reservable bandwidth for a NIC is determined by media speed (link speed) of NIC multiplied by Packet Scheduler's configuration variable (NonBestEffortLimit percentage). A flow of priority 3(standard) is allocated "best effort" bandwidth, so it's not confined within this reservable bandwidth limit. WinTC displays the following information before applying bandwidth rules to a NIC: Total reservable bandwidth: X bytes Remaining reservable bandwidth: Y bytes "wintc -i -v" shows the same information that is in effect currently. The following is a table of typical network media speed and their default reservable bandwidths. media speed 100% 80%(WinXP default) 20%(Win2K default) Ether 10Mbps 1250000bytes 1000000bytes 250000bytes Ether 100Mbps 12500000bytes 10000000bytes 2500000bytes wireless(b) 1375000bytes 1100000bytes 275000bytes wireless(g) 5400000bytes Note: Windows XP documentation states that the default value (when unspecified) is 20(%). However the real default value is 80(%). You can change the value of NonBestEffortLimit with either of the following procedures: Windows XP Professional - type "gpedit.msc" to start Group Policy editor. - Navigate to "Local Computer Policy" -> "Computer Configuraton" -> "Administrative Templates" -> "Network" -> "QoS Packet Scheduler" to open "Limit reservable bandwidth". - enter a value of 0 from 100 in decimal. Windows 2000 Professional and Windows XP Home - Add the following registry entry: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Psched Value Name: NonBestEffortLimit Data Type: DWORD Value Value Data: 0-100 (in decimal) - to specify the value for each NIC, add it to the following instead: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Psched\Parameters\Adapters\{Adpater-ID} Overlapping Filters ------------------- [Note: PSDK documentation on Traffic Control API is not clear about overlapping filter ranges. Information in this section is derived solely from my experiments on Windows XP SP1.] If WinTC says "[filter-name]: Possibly overlapping filters. Check port/address range" you must make sure that IP address range and/or port range that you define are not overlapping. Address ranges and port ranges that two filters define must be either 1) disjoint (no overlapping range), or 2) one filter's range is a proper subset of the other's range. Any other overlapping ranges are not allowed. This is to ensure that packet scheduler, upon packet inspection, can pick up a single filter without any ambiguity or ordering of filters. This limitation is actually very severe and might render this packet scheduler useless in some applications. Disjoint ranges - OK |---- filter-1 ----| |---- filter-2 ----| Proper subset - OK (subset filter applies) |---- filter-1 ----| |--filter-2--| Overlapping ranges - NG (can't determine which filter to apply) |---- filter-1 ----| |---- filter-2 ----| ex - [NG] overlapping ranges (1) filt-1 : srcport=80 dstport=* srcaddr=* dstaddr=* filt-2 : srcport=* dstport=433 srcaddr=* dstaddr=* ex - OK disjoint ranges filt-1 : srcport=8888 dstport=* srcaddr=* dstaddr=192.168.0.1/24 filt-2 : srcport=8888 dstport=* srcaddr=* dstaddr=130.32.0.1/8 ex - OK proper subset (1) filt-1 : srcport=0x2000/4 dstport=* srcaddr=* dstaddr=* filt-2 : srcport=8888 dstport=* srcaddr=* dstaddr=* ex - OK proper subset (2) filt-1 : srcport=80 dstport=* srcaddr=* dstaddr=* filt-2 : srcport=80 dstport=* srcaddr=* dstaddr=192.168.0.1/24 TC API ------ Details about how WinTC uses TC API. WinTC Priority TC Service Type Shaper Mode (default) 1 (high) Guaranteed(3) shape 2 (medium) Controlled Load(2) shape (unknown until 0.2.8 due to bug) 3 (standard) Qualitative (13) shape (unknown until 0.2.8 due to bug) or Best Effort(1) WinTC limit= Shaper Mode yes (default) shape (queue packets to achive limit) discard discard (discard packets to achieve limit) no borrow (no shape, use unused bandwidth) About TokenBucketSize, PeakBandwidth If you specify any of the above parameters, the flow is put into advanced mode. Otherwise, the flow remains in basic mode. In basic mode, the following values are set: TokenRate = TokenBucketSize = PeakBandwidth = In advanced mode, the following values are set: TokenRate = TokenBucketSize = PeakBandwidth = In advanced mode, if you don't specify a parameter, value zero is assumed. Network Monitor Tools? ------------------------- You can find links to many network packet analyzer programs on http://winpcap.polito.it/misc/links.htm. However, I couldn't find a tool that is most suitable for our purpose, that is, to monitor network usage per source/destination port. TODO ---- - experiment with shape/non-shape... (done in 0.2.8) - extend assign_filter to allow multiple filters to be assinged to a flow. (this is just a syntax enhancement, you can use multiple assign_filter params to achieve the same thing) - support UDP (done, not tested yet) - support ICMP - allow NIC to be specified in individual flow definition. Changes ------- 0.2.9 - new param in "rbp.conf": rbp_quit_if_none_active. - increased max # of flows from 32 to 256 increased max # of filters from 64 to 256 increased max # of assigns from 32 to 256 EOF