First published on TechNet on Jun 13, 2017
Hello, Michael C. Bazarewsky here again, with another short clarification post. In February, we published Features that are removed or deprecated in Windows 10 Creators Update (KB 4014193). Someone I follow on Twitter noticed this part: The X's here indicate those features are deprecated. This occasionally comes up still on Twitter, with at least one person seeing this as a real issue... But I was curious – what was the driving factor behind this deprecation? After all, you'd expect that if features improve performance reliably, and are in heavy use, we wouldn't deprecate them, right? Well, it turns out, by phrasing the question that way, I've walked you down the garden path a bit. I reached out internally, and found out some interesting information that I'm not sure was particularly widely known, although you can see hints of it. Before explaining why they are deprecated, though, I should explain what each of these features did, in theory, to explain why they were ever listed as features at all. After all, you can't really understand the implications of a change without understanding the original state, right? First, let's talk about TCP Chimney, which is part of a larger concept known as TCP Offload Engine (TOE.) TCP Chimney moves part of basic TCP processing to a dedicated circuit on a network card. There are different levels of TOE implementation; TCP Chimney is a subset where the basic setup of a TCP connection is still handled by the host operating system stack, but once a connection is active, the encapsulation and de-encapsulation of data from the network stack into TCP packets over the connection is handled by the offload engine. The benefit is that it removes workload from the operating system and the host system processor cores. However, this benefit comes with some noticeable costs, as well:
Windows first introduced TCP Chimney support as part of the Windows Server 2003 Scalable Networking Pack . As explained in KB 912222 , even when first released, TCP Chimney had conflicts with other possible performance enhancements – so even at release, a customer saw the issue of not being able to leverage intelligence in the operating system network stack. Over time, as users called in with support cases, network card drivers were released to the Windows Update Catalog, and operating systems and servers moved forward, we found that several things were true:
Thus, the end result of all of this is that the TCP Chimney deprecation in Windows 10 Creators Update is really not a new thing, because disabling it by default was a signal of the future direction. Furthermore, there are no current mainstream network cards that implement this feature, and customers are not reporting a need for this functionality. So, although deprecation of a feature is something customers generally need to be aware of and plan for, in this case, that's not a real life concern. But what about the second deprecated feature, IPsec Task Offload? Well, this is another case of the concept of transferring computing responsibility from the host processor to the network card. However, this is not basic processing of TCP packets in this case. Instead, IPsec Task Offload, as the name implies, moves the encryption and decryption tasks for network data protected with IPsec to the network card. As you can imagine, this also requires a smarter network card, with more complicated firmware. Thus, all of the issues around updates and patches that were present for TCP Chimney are also present here. Further, because the whole point of IPsec is to secure network communications, security issues are arguably more critical to correct in this scenario. Now, all of that may be okay if there was a sufficient benefit to customers. However, again based on customer support cases and driver support, we know that several things are true:
You may notice one of those points – the point around the number of support cases – is a duplicate from the list for TCP Chimney. This is not a coincidence. In both cases, it's clear from customer interaction that real-world impact of deprecation of these features will be near zero. And, as mentioned above, because deprecation is not the same as removal – the whole point of deprecation is to act as a customer warning point and allow reaction from the user community and ensure that we aren't missing something or breaking existing environments – there's always the chance for us to be proven wrong on this. I hope you find this information helpful in understanding some of the thinking behind these features being deprecated (and, by extension, some of what we use in general for these decisions.) Thanks! p.s. What if you feel you are indeed impacted by these changes? In that case, that's what support channels are for. Open a support case, or, if you have Premier support, request a design change (DCR) through your account team. That's why we have those channels :smiling_face_with_smiling_eyes: p.p.s. special thanks to Daniel Havey, Mihai Peicu, Praveen Balasubramanian, Don Stanwyck, and Doug Stamper for technical review assistance and background information!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.