They would need to know that the HTTPS traffic flowing through their network is from an MSFS client. Not sure if they could determine that without doing HTTPS inspection. The most they could get without is the destination, and those IP’s might be used by other services.
[update: this may apply to some download troubles, but may not be what’s going on described here because it does sound a bit more consistent than i’d expect from network probs based on elsewhere in the thread]
I’m not talking about throttling at all, but packet loss and full pipes. This’ll depend on what you download, from where, when, and what the current network conditions are at your ISP and between the ISP and wherever the CDN servers are. (There may also be different servers for different things, and they might be located in different places and go through different network routes. It’s very hard to diagnose these things!) Downloads that start slow (lots of packet loss) then get fast (less packet loss) then get slow again (more packet loss) sounds consistent with the network trouble theory.
Of course, without network engineers on both ends it’s hard to tell. Good luck with your troubles.
Note that if you’re measuring bandwidth via some external bandwidth-measuring program, that will tell you nothing specific about the route to the CDN server and whether there’s packet loss or bandwidth limitations on that route (in one or both directions).
So this packet loss is
- depending (and differs) on what addon is being downloaded,
- the exact same slowdown, at the same point of download (the beginning and only the beginning),
- for the same length of time (generally a minute or two but depends on the addon being downloaded) and
- is repeatable if I delete and re-download the same addon either a fews minutes or a few days later?
We’ll have to agree to differ as that’s not consistent with network trouble theory in my experience 
Of course it is possible that an individual addon comes from a different CDN which would at least explain some of the inconsistencies between addons but even then it wouldn’t explain the repeability.
Edit: as an example of what I mean…I was forced to re-download the aviator liveries. 6Gb worth. Instantly my speed hit 20-40mbps. A few minutes later I downloaded the Ford TriMotor. 2.5mbps for 4 minutes followed by 20-40mbps. I deleted and repeated those 2 downloads some days later with exactly the same results.
Ah then it sounds like you have a different problem, and my suggestion to look at network likely won’t help. [clarified] Good luck!
Well apart from all the other posters who are experiencing it (on this thread and others) 
Edit: sorry to sound ungrateful for your help. It’s just that your suggestions are perfectly correct in general cases but don’t seem applicable in this issue.
No worries. Sounds like there’s other problems going on too and I hope folks work them out!
I just ran some download tests of the Ford Trimotor.
I tried this three times, and identified two IP addresses in the 13.107.0.0 range, the last one was 13.107.246.64. When I abort the download, that IP address ceases to pop up in Wireshark.
When I search for this in the list of Azure IP’s it does not appear there. That suggests that either MSFS is downloading content from CDN servers that are not part of the Azure range, or that list I was referencing is out of date.
According to Robtex that IP is owned by Microsoft, but is in Redmond, US.
When I was downloading it was coming in at the often seen ~2Mbps.
Another download kicked off, now coming from 40.90.65.40, now at a blistering 3Mbps. Again, this one is not present on the Azure IP list.
I’ve started to build a list of IP’s, adding them to a local firewall rule to block access to those IP’s.
With these two in place I couldn’t download anything from the MP, so I relaunched the sim. I downloaded my test package again, the Ford Trimotor, and I’m now downloading at ~80Mbps.
The current IP is 104.212.67.228.
So there are clearly some CDN’s out there that either have issues, or are overloaded. I’m starting to think I should have kept this to myself, as everyone will jump on the working ones now. 
This is what I’m looking at in Wireshark. Capture filter is looking at only TCP 443 traffic.
The windows firewall rule is very simple:
New Outbound rule:
Add the IP’s to block in the bottom window:
Action is block:
Now give the rule a name, and finish.
At one point I noticed that downloads were being blocked, but those two IP’s were not appearing anywhere. I closed the sim, and it then failed to load, so there may be some unwanted side effects of this method. It’s wide open so I could try constraining it to only 443 traffic.
I’ve had mixed results so far, and built up a list of CDN servers that are giving me slow downloads. Annoyingly though, sometimes it seems to work, and does use an IP not in the list, then others it refuses to use something else so refuses to download at all.
On a hunch I redid the rule as an incoming rule. The theory here is that the client will be able to communicate out, never get a response, assume the server is down, then pick the next. This does allow the sim to launch, but then still downloads from one of those IP’s that it is supposed to block. On time I did get a repeat of a 70-80Mbps download rate, but with incoming only 99% of the time it downloads at 3Mbps.
I’m pretty convinced that this problem is at the CDN level, and some are offering nothing more than ~3Mbps pretty consistently.
The list I have so far is:
40.90.65.161
40.90.65.164
40.90.65.128
13.107.213.57
13.107.213.64
13.107.213.67
13.107.246.57
13.107.246.64
13.107.246.67
Looking back up at this list as I add those IP’s that are giving ~2-3Mbps, It looks like these /24 networks are affected, so 40.90.65.0/24, 13.107.213.0/24, and 13.107.246.0/24.
The one IP that gave me pretty good speeds, though I have seen better in the past very rarely, was:
104.212.67.228
If I could find a reliable way to lock it to that somehow I would.
Getting ~23-30 Mbps from 40.90.65.2
Getting 3Mbps from 104.212.67.148, which is the same network as the IP where I was getting 80Mbps, so that’s that idea gone. 
With the outgoing blocks in place, if MSFS tries to use one of those blocked IP’s it will fail to load correctly, instead showing a screen that looks like it wants to perform a full re-install. Quite why it equates a loss of connectivity as the sim not being installed is beyond me.
ALT+F4 from this, then launch the sim. I had to do this three times before it chose the IP above, which is not blocked. It doesn’t look like the sim has a robust method of checking for which servers it can actually get to, and instead gives up too easily.
Actually if you leave it on on that screen long enough it does reconnect. I just wasn’t brave enough to hit Continue in case it kicked off a re-install from scratch.
Setup a packet capture and look at the Window Size (make sure you get the 3way handshake to get the scaling factor if present), do some pings to get the RTT and go here: Network Throughput Calculator - WintelGuy.com
Do some trace routes too.
Thanks some fantastic in depth analysis there @hobanagerik but you didn’t seem to observe the fact that after a few minutes at 2.5mbps in my experience the speed jumps back to expected speeds 20-30mbps or even 100+ if it’s a large file. That holds until the next file in the download then you’re back at 2.5mbps! This behaviour is also repeatable and doesn’t depend on time of day or day of week. This is so systematic that I believe it is by design (introduced in late June) but that doesn’t explain why it’s not affecting everyone. And of course with certain addons it doesn’t occur at all (see my example of the aviator paints).
I could understand an overloaded CDN throttling speeds due to loading but not with such repetitive and predictable behaviour.
I could live with this behaviour IF it only occurred at the start of a download session or even at the start of a particular addon but this speed drop occurs at the beginning of every individual zip file in an addon of which there can be many and hence the average download speed tanking.
Could it be increasing speed because the downloader times out after a certain amount of slow-download times, then reconnects to the next server in the list or something? I wonder.
It’s a possibility but the amount of time spent at 2.5mbps download speed is exactly the same with repeated downloads of the exact same addon. No randomness at all is observed.
That fits, then. Identical timeout is very suspicious!
(Note that randomness is not required. If it’s consistently connecting to the same first server, and consistently going through the same route, and that route is constrained by a narrow bandwidth limitation, then that’s going to be the same every time.)
Not to me I’m afraid.
I’m off to catch a train I’ll explain my reasoning later…
Well whether they’re a sign of deliberate throttling or a sign of network configuration issues, it’s very suspicious to people who have experienced network problems before. Good luck!
I never mentioned malicious
Fair enough, I’ve amended my post.
I see this problem on just about every marketplace download I do these days. I could probably live with it, but many downlaods are broken into PARTS which all reset the speed back to 2MBPS again, so a 1GB downlaod in 2 or 3 parts can take ages to download. Not sure I could even reinstall MS content if I had to from scratch as this issue would make it highly impractical.
I never see it with sim updates, but it’s nearly always there for marketplace/CM updates/downloads.
Been happening for me on every CM downlaod since spring this year, used to be fine before that.
I didn’t wait for it to finish the entire download, and perhaps I should. I didn’t observe a change in speed for about 2-3 minutes of it starting. When I had blocked off some of those other IP’s, and it landed on one that gave me better than ~3Mbps, it started off at 80Mbps, then stayed at around 70Mbps for the rest of the test.
The only time I ever saw it switch servers was when I was playing around with the firewall rule. For the most part it will stick to one or two servers. If you block those, to actually get it to shift you have to close the sim down, then relaunch it.