We'll be slurping your data faster!!!
Can't really wait for it!!!
Microsoft has announced it will add five new features – some experimental - to the TCP stack it will ship in Windows Server 2016 and the Anniversary Update to Windows 10. Redmond says the following five features will make it into its new TCP stack: TCP Fast Open (TFO) for zero RTT TCP connection setup. IETF RFC 7413 Initial …
The last thing I want in MS closed source proprietary networking code. I don't care how efficient it is.
"To continue your download, please press the onscreen 'purchase' button to pay for another 20 minutes of access."
"We're sorry, your Linux system does not seem to be using Microsoft approved TCP/IP packets and your connection has been dropped."
"Your download will take 9h 47m as other traffic has been prioritized over you. For faster downloads, please click on our Premium Services website for a price schedule."
If you think I'm wrong, you've never dealt with them before.
Being less agressive during periods of high latency was specifically mentioned
"LEDBAT will stop Windows competing aggressively for bandwidth during times of high latency"
yes. it's ABOUT TIME on THAT one... not like I hadn't specifically complained directly to them about that OVER A YEAR AGO (and others as well).
it's probably the WORST thing that Micro-shaft does with their forced updates: DOMINATE your intarweb connection with WHATEVER SCHTUFF *THEY* want to use it for, at a time of *THEIR* choosing, even if you're watching streamed media content. OOPS - interruption - because, Micro-shaft.
The Windows TCP stack used to be one of the best and most stable, but like everything else companies leaf fog each other, so once the windows TCP stack got overtaken, Microsoft setup a team to do everything possible to once again make it the best.
So for the next few years it may be the best, then it will taken overtaken again.
No company wants to be making small changes to their TCP stack all the time due to the cost of testing etc. Therefore a TCP stack will be frozen for many years, until there are enough large image changes to justify the cost of testing.
"Yeah, because we all have sooo much experience of 40GB connections"
Some of us do. And believe me, there's bugger all measurable difference in the IP stack between Windows and Linux performance on that (or any) kit; certainly not enough to be worth singing praises in forums. In the real world there are tons of other variables that have a bigger impact (e.g. hardware, infrastructure, etc) that make such statements completely worthless without a lot more qualification.
And believe me, all those hardware offload features in NICs are not all they are cracked out to be either - I've often had to turn this off due to buggy drivers or firmware from NIC vendors (*cough* Broadcom *cough*).
At the application layer things can be a bit different (NFS, CIFS, HTTP, etc, etc) and can swing either way depending on the service and OS. But there are so many variables there that we are heading way outside the scope of this thread. :)
Now all that said, it's good to see Microsoft making improvements. Everybody benefits from this sort of thing and shouting that $PREFERRED_OS is the best is just silly here.
Everybody benefits from this sort of thing and shouting that $PREFERRED_OS is the best is just silly here.
Indeed. Especially as no-one mentioned the true winner: FreeBSD.
Even Facebook admits that Linux is playing catchup: http://www.theregister.co.uk/2014/08/07/facebook_wants_linux_networking_as_good_as_freebsd/
"there's bugger all measurable difference in the IP stack between Windows and Linux performance on that (or any) kit
That's not my experience. Not a vast difference but at extreme bandwidth use, Windows Server is generally measurably faster and has lower CPU use.
"Yeah, because we all have sooo much experience of 40GB connections"
Just because you cant afford modern kit, doesn't mean everybody can't. A new blade chassis setup would likely be running 40gbit uplinks these days and 40 gbit cards in the blades themselves are not that expensive where required.
And there are cheaper ways to join the club if you can't afford new:
"It's generally the fastest"
Yes. I especially liked how they made it so the OS established the TCP connections and began the application layer things before the application knew anything about the connection. It made IIS seem faster. But when too many connections came in and all the little white lies started building up too high, the OS choked.
Apparently they fixed that by increasing the amount of memory it could use to store all the layer violations.
Actually, there has been a TCP stack in Windows NT since 3.51 (maybe even 3.5); it was an OEM-ed stack back then, but it was there. I don't recall whether or not you had to pay extra for it, but...
(That stack, and all of the other OEM TCP stacks on Windows (NT and otherwise), ultimately lead to the development of the Windows Sockets interface spec, which we should all be happy about - it may not be quite the same as *nix sockets, but it unified protocol access on Windows, which was a Very Good Thing)
*(and I couldn't agree more about NetBIOS and NetBeui (NetBIOS is the interface, NetBeui is the protocol used in early Windows NT versions). NetBeui is a ghastly protocol (holes in the state machine!) from a bygone era that we're well shed of, and NetBIOS being retired is a good thing as well.)
>Actually, there has been a TCP stack in Windows NT since 3.51 (maybe even 3.5);
Actually, there has been a MS TCP stack for Windows since WFW 3.11 (maybe even Win 3.1). It was not, as I recall, a free product until it was available free as the NT client.
Late reply as always.... Life is busy.
The TCP stack in windows has an interesting history. They built it into win 3.11 windows 3.1 did not have support, eek was that win 3 and 3.1? damn I forget. You got full support with Trumpet Winsock. Quite a good TCP layer, especially as it didn't hang up your modem on reboot (windows loved the blue screen back then)
But MS felt threatened.... and built something not as good, bundled it in.
So afterwards of course, there were artificial limitations on the number of connections you could maintain, and winsock wasn't quite the same as unix socket layer, it had its own quirks if I remember correctly.
Couldn't let their mainstream OS become a server OS, but that could be made into a sharing limitation.
and the fun moved elsewhere, DHCP and DNS quirks....
finally they let Cisco redo the ip stack in 7? was it?
MS have form, opportunity, but this time around I don't think they have the motivation, at least I sure as hell hope they don't.
Microsoft has announced it will add five new features – some experimental - to the TCP stack it will ship in Windows Server 2016 and the Anniversary Update to Windows 10.
Am I misinterpreting the anniversary update? Is that not a live branch thing? If it's just a way of saying "It'll be rolled out over time to machines after the anniversary update has been deployed" then you're probably correct. I assumed it to mean it was part of that update landing in August but not yet being tested beyond Redmond's walls.
What a great idea! I bet Microsoft are glad you suggested that, as they'd never have thought of it... Oh, hang on...
Some things, for example TCP Fast Open, have been in the fast ring for quite some time. I know because there was an issue with the implementation a few months ago that meant some sites using TCP fast open would not work properly - notably some Google properties. This was withdrawn, fixed and it's back in the fast ring as an optional setting within edge, turned on via a setting in about:flags. It's now working with every site I tried it on.
I remember when Microsoft took it upon themselves to tweak the Windows file copy engine as part of making Vista great. Whereas Linux had managed more than acceptable performance for years by reading the source file in chunks and writing those chunks to the destination file, the Windows Vista copy geniuses knew better and implemented some absurdly complex scheme involving changes to the network driver layer and more, as described here: https://blogs.technet.microsoft.com/markrussinovich/2008/02/04/inside-vista-sp1-file-copy-improvements/
Unfortunately the great unwashed masses were not grateful for all of this effort, pointing out that in the real world of copying actual files, not only was Vista much slower than XP was (by orders of magnitude!), but that the Vista copy engine was actually slower than every other approach too - even being roundly beaten by third party copying applications running on Vista.
So forgive my cynicism, because somehow I don't think Microsoft will succeed here at all. Quite the opposite.
I'll stick with anything but Windows.
"Unfortunately the great unwashed masses were not grateful for all of this effort, pointing out that in the real world of copying actual files, not only was Vista much slower than XP was (by orders of magnitude!), "
That was fixed long ago in SP1:
Windows file copy is still completely f***ed up in one serious respect. drag a big file from one drive to another, then while it's copying, drag another file, then another. Windows attempts to copy all the files at the same time, interleaving the operations and causing disk contention and thrashing, when simply copying them in sequence would be (in my tests) up to 5 times quicker.
"Well, you told it to copy them all at the same time...."
No, you told it to copy them all; nothing suggests they have to be done concurrently. If you tell your favorite music-playing device to play ten songs, do you expect them all to be played at the same time? Just because Windows has always done it this way and you've come to accept that as normal does not mean that that's what you told it to do.
If there's a better way of doing this than all at the same time, I'd prefer that the OS be clever enough to do it that way. That's one of the things I noticed about Linux Mint that pleasantly surprised me coming from Windows-- Nemo (the file manager) queues the second copy operation and appends the dialog to the first one, clearly indicating that it is queued for copy, where you can then click the "go" button to copy concurrently, or click the stop button on either operation to cancel.
It's so simple-- anyone capable of understanding a file copy progress meter in the first place can grasp the concept of the second copy operation waiting for the first one to be completed (especially when the dialog tells you exactly that), so the idea that everything has to be dumbed down for the beginner doesn't really work.
I second that irritation...
There's nothing quite like having to hand hold a windows machine for a relative when you're copying photos from various cameras whilst trying to organise some other folders while you're at it.
Now watch as 3 different copy windows go from a few seconds to minutes, then hours because....reasons.
TCP starts sending packets slowly until it finds out how fast they can be sent without a router dropping them due to a slow network, or lack of buffer space etc. Therefore a short lived connection may never get up to full speed.
This has always been an issue in IP networks, as there is no central system to setup connections and decide what speed each computer can send data at….. This is also one of the reasons that IP networks scaled so well……
I understand you're joking. However, Linux has had most of these things for years. The exception is LEDBAT, RFC 6817. The actual dates are
RFC 7413 TCP Fast Open (TFO): kernel 3.13, 19 Jan 2014, https://kernelnewbies.org/Linux_3.13
Initial Congestion Window 10 (ICW10): kernel 2.6.39, 18 May 2011, https://kernelnewbies.org/Linux_2_6_39
TCP Recent ACKnowledgment: 4.4, 10 Jan 2016, https://kernelnewbies.org/Linux_4.4
Tail Loss Probe: 3.10, 30 Jun 2013, https://kernelnewbies.org/Linux_3.10
TCP LEDBAT RFC 6817: As far as I can tell, Linux does not have this yet.
"The Linux IP stack has had all these and more since 1976"
Looks like nobody got the humor. and you got more downvotes than me. NOW I'm envious...
(/me points out Linux was invented in 1990's, but the UNIX stack would've existed back then...)
At one time NT had an implementation of the BSD stack, with appropriate copyright statements in their documentation. They should've stuck with that, and tracked the BSDs.
Just disable telemetry. That would have the same effect.
They could also stop that "calculating" bollocks on file transfers and simply display a throughput graph.
Most of know how big the folder is we're trying to copy and can perform basic maths...I dont need a wildly inaccurate estimate for the file transfer dialog thank you very much.
>> They could also stop that "calculating" bollocks on file transfers and simply display a throughput graph.
Have you looked at Windows lately? Not only do you get a throughput graph for a file copy, you have the ability to pause the transfer - which is very useful if you're doing multiple transfers at the same time to a slow destination (or from a slow source).
I find the current file copy progress indicators on Windows to be far more useful than the stupid analog progress bar Linux provides...
Linux is a kernel. Kernels do not have progress bars!
Desktop environments do, though, and unlike Windows, you can choose from many different desktop environments that all work with the Linux kernel; Unity, Gnome, KDE, Cinnamon, Mate being among the better known ones. They each have their own way of handling file copies, and if you don't like it, you can choose another-- there's no such thing as the one "stupid" way Linux does it.
I'm certainly no fan of Microsoft, but if these had been listed as coming in the next version of Linux, everyone would be cheering them on. If Google was adding them to Android, people would be making tired jokes about how "Apple will patent this tomorrow and sue".
These are all standards or future standards, and the IETF always adds things like this in a way such that if the other side of the connection doesn't know about them, then they either have no ill effect or no effect at all. People are talking like adding these things are going to break the internet or something, sheesh.
If you it makes any of you feel any better, Linux already implemented the first and fourth ones, Google was the one who thought up the second one, and Google is already testing the third one in their Linux servers. The fifth matters mostly for Bittorrent...
"I'm certainly no fan of Microsoft, but if these had been listed as coming in the next version of Linux, everyone would be cheering them on."
Context is everything.
Microsoft has been under fire for abusing their customers with adware that in one case masqueraded as a security increase like a Trojan horse, advertising a so-called operating system that infects your system like a worm (try and stop it!) and phones home like spyware, soft-bricking many people's PCs in the process. While it's certainly good to make improvements to underhood things like the TCP/IP stack, it kind of reminds me of rearranging deck chairs on the deck of the Titanic as it sinks-- of all of the complaints people have been making against Microsoft lately, the quality of the TCP/IP stack isn't high on the list. It's like a press release that is meant to convey the idea that "despite the complaints, it's business as usual here at Microsoft. Look, we're working on networking stacks here; we're not even worried!"
Which, of course, means they're worried. Still, they keep going, full speed ahead, in the same direction...
Linux is far from perfect, but it hasn't earned the sort of cynicism Microsoft has. Bashing Microsoft is more than just a hobby-- it's just good sense to wonder what Microsoft's angle is when they claim to be "improving" something.
I agree one should be suspicious of Microsoft. I think we should be even more suspicious of Google, who have combined Microsoft's "we want to own the world" mentality with trying to collect personal data on everyone in the world to such an extent that George Orwell would be shocked. Yeah, Microsoft is trying to imitate them in this with Windows 10, but they are so incompetent these days it is like watching an 80 year old man try to fight someone. You don't know whether to laugh or feel sorry for them.
Same goes for Facebook, BTW. Both of them I worry more about than Microsoft these days...
Certainly we should be suspicious of Google and Facebook. The latter is easily avoided; I have the entire facebook.com site blacklisted in my adblocker, so done and done.
Google can be avoided the same way, but unlike Facebook, they offer some services I find useful, so a combination of Firefox addons thwart the scripts and tracking cookies that give Google its spying power. Combined with dynamic IP addresses that change at least once a day, and that I don't disclose any personal information online if I can avoid it, pretty much takes care of the Google threat on my PC. They can get short strings of data, but with no cookies or IP address to connect them back to any other short strings, it's not useful to them.
I have an Android tablet, but I know it's Google, so there is nothing sensitive on it. It's a toy, not a serious machine like my PC, and it has fallen into disuse. I don't have a smart phone and I doubt that will change.
Microsoft is different. I've been using Windows and MS-DOS for 26 years; all my personal stuff is on my PC. The things I would never disclose on a Google site or on my Android tablet are all right here. So when MS clumsily decides to try what Google does very efficiently, they still have a much greater chance of compromising my private data than Google does. And if they are clumsy and incompetent in their spying, it doesn't mean they won't get anything-- it could also mean they could end up inadvertently grabbing personal info they promised to anonymize, and that they might leave that data unprotected and vulnerable to black hats.
The OS maker has to be held to a higher standard. It must unambiguously serve only the needs of the user; anything else is a breach of the trust a user places on the OS. Other versions of Windows have dabbled around the edges of breaching the trust, like the Win 10 spying that was backported to WIn 7 and 8, but they've always been avoidable (don't install the updates) and removable (uninstall the updates).
That's not possible with Win 10, through normal means at least, and you never know when the next unavoidable update will change the rules again and bypass any hacks you had in place to block Windows 10 from doing what its meant to do. The entire forced update system was put in place to benefit MS, the spying is to benefit MS, the ads are to benefit MS, the focus on apps on the desktop and the Windows store is to benefit MS, the vendor lockin and tie-in to other MS products (like Cortana only using Bing) is to benefit MS, and there are lots of other examples too numerous to list.
An OS that cannot be trusted should not be trusted.
I don't know about that embrace and extend stuff. That was before my time at Windows and has nothing to do with what we are doing now.
Truthfully, I can tell you all we want to do is make the Internet a better place for Windows users and for everyone else. That is why we have been updating our stack and that is why we will continue doing so. The way I see it is that we are doing a good thing and I am catching a lot of flak for it. Oh well! No good deed goes unpunished :)!
The way I see it, I don't care who invented what. If it is the right thing to do then Windows will do it because that's the kind of heart that we have. If you don't believe me then check out our second wave of updates: https://blogs.technet.microsoft.com/networking/2017/07/13/core-network-stack-features-in-the-creators-update-for-windows-10/
From Windows Stack with love :)
Biting the hand that feeds IT © 1998–2019