Edit: See this post for a working practical config with a router that uses these settings.
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.
Crashplan
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.
I tried to follow your guide here by I still get DSCP of 0 regardless of what I set for gp.
Where are you setting the value?
I also followed your steps but still get DSCP as 0
http://support2.microsoft.com/kb/2733528
For me, your procedure works after configure “Do not use NLA”…
Thanks!
Good to hear that it worked for you. I seem to recall that had no effect for me. So many permutations..
Hello, have you enable or installed the QoS Packet Scheduler on your interface?
I have an “Intel(R) Centrino(R) Ultimate-N 6300 AGN” adapter, which doesn’t indicate any specific options to enable the QoS packet scheduler, other than for ad-hoc mode which isn’t relevant. I don’t recall specifically enabling anything.
You, sir, are my new hero. A thousand Internets shall be awarded in your praise.
Paul, I am running Windows 8.1 (basic, not pro), which does not have the group policy editor. I was wondering if you know which registry settings are modified/created, so that I can manually make the changes. Thanks!
http://technet.microsoft.com/en-us/library/hh967468.aspx
Hi Mike,
I’ve updated this post with a screenshot of the resultant registry entry for the created policy.
Paul,
Changing the DSCP value in Crashplan to 32 results in a DSCP value of 8 in the packets. You can see some logic in it as I believe DSCP uses the high nibble. But is not intuitive. Likewise setting their predefined values appears to have no effect.
The value of using the Crashplan route is it works on Linux & OS X as well.
Regards
Andy
Hi Andy,
I tried with ’32’ and got the same result with DSCP values of zero.
Pingback: Crashplan DSCP QoS setting on MacOS does not work?