Update 2013-05-30: The solution described at the end of this post is applicable to Windows 7 Professional and other non-‘home’ editions. Windows 7 Home Editions do not appear to have group policy editor (gpedit.msc) installed as standard.
I spent a fair amount of time trying to get to the bottom of this and so thought I would share my experiences, and partial successes. This post describes the issues I had trying to stop Crashplan’s upload traffic slowing down everything else on the network while utilising the available bandwidth for very large uploads. It talks about Differentiated Services Code Point or DSCP, QoS, Netmon packet monitor, Group Policy settings, and various unsuccessful fixes to the problem of Crashplans DSCP setting having no apparent effect either due to a bug or limitations of Windows 7. This post doesn’t discuss router configuration (to be part of a separate post), just Crashplan and DSCP on Windows 7.
I started using Crashplan as an online backup solution. I soon found that the upload burden was taking its toll on the network – any other device in my home would be slow and laggy to browse web pages while Crashplan was doing its uploading thing. Currently the home cable serivce is rated as 10mbps down, 0.25mbps up (I know is pretty low, I need to upgrade).
I thought of the QoS features of my SOHO router – a Draytek 2920, to improve the traffic flow. In order to utilise this I looked into the network TOS & DSCP settings within Crashplan which allows us to select four preset options or specify a custom DSCP value. For the record, I’m no networking expert, so this is based on what I learnt over a few days messing around with things and a lot of Googling.
Windows 7 by default appears to send out all packets with DSCP value of zero. Some applications may set or offer configurations for other values. By flagging CrashPlan traffic appropriately, we should be able to handle it in a different way at the router, that is, give it less priority, or give other traffic higher priority.
I tried various settings for TOS from ‘Low’, ‘Normal’, ‘Reliability’ and even custom DSCP values of ‘1’, ‘8’ and ’23’ but no matter what setting I choose, the outbound packets to the CrashPlan repository were not being marked with the expected DSCP values. Using netmon it is easy enough to run a quick capture and find packets being sent from the Crashplan backup service to a remote ip on port 443. Don’t make the mistake I did which was to think that all Crashplan traffic goes out on port 4242, those settings are for your own homebrew backups. I’m only talking about using Crashplans paid-for backup service ‘Crashplan Central’ which sends to destination port 443. The Netmon output is shown below.
Cited issues and registry workarounds
There are several. There’s a discussion on Crashplan support forum (requires login) which is useful but inconclusive. Note that Crashplan is available for platforms other than Windows, so one persons success and remedy may not be relevant to us on Win7. There are several workarounds based on the principle that windows is not allowing applications to set the DSCP value at all, which tends falls towards two settings – DisableUserTOSSetting which doesn’t appear to be relevant to Win7, and Do not use NLA which is.
UPDATE 2015-May-09: While ‘Do not use NLA’ registry setting did not allow Crashplan itself to set DSCP, it is required for the steps below to work. Without this setting, DSCP will remain at zero.
Having tried both of these settings, including reboots and restarts of the Crashplan service I found no change in the NetMon figures which still showed a default DSCP value of zero. I’ve not found definite account of someone running Crashplan on Windows 7 with DSCP being applied, so I’ve concluded for the time being that Crashplan on Win7 either doesn’t set DSCP values because of an application bug or cannot set DSCP values due to Windows itself.
Successfully setting DSCP
Stepping away from Crashplan’s network configuration options, Windows itself has configurable QOS policies which can do precisely what we want, which is mark only Crashplan traffic to destination port 443 and not any other traffic on port 443 such as HTTPS browsing. After all, the aim of all this is to depreciate the priority of Crashplan bulk traffic such that pretty much everything else, including https, takes priority.
To do this, you’ll need to open the group policy editor. From the command line run ‘gpedit.msc’ or search the start menu for ‘group policy editor’ to arrive at the same place. Expand Local computer policy > Computer configuration > Windows Settings > Policy-based QoS. Right-click and create a new policy specifying all traffic from the Crashplanservice.exe process to destination port 443 to be set with the required DSCP value. Finish, and you’re all done.
The resultant registry entry is shown below:
Within the group policy editor, right-clicking ‘policy based qos’ shows an ‘advanced settings’ option. Within here, you can specify whether applications are allowed to set their own DSCP values. To check this wasn’t the issue all along, I enabled this, and removed my qos policy to see if the Crashplan setting would have any effect – unfortunately not, DSCP values were back to zero. As suggested in the comments below, I also tried setting the DSCP value in crashplan to ’32’ as an equivalent to DSCP value of 8, both again this had no apparent effect for me with packets marked zero.
I created a video showing Netmon before and after setting the policy. The effect is also immediate, no restarts or service or machine required. In the example I’ve used a a DSCP decimal value of 8 (001000) which is is ‘low priority best effort’ class designation, suitable for bulk traffic such as data mirroring – I’ll cite this Ja.net document as my reference. Page 7 is useful as it lists a practical implementation of the numerous traffic classes available.
Hope this helps others trying to solve this issue.