This is not correct. TCP does not know the total amount of bandwidth available on a network link just like it does not know the total amount of unused bandwidth available on the same link - hence the need for additive increase.
What will happen is that two TCPs will share the available bandwidth (or close to it) via AIMD. However, if you've ever uploaded a file on an asynchronous Internet connection (i.e. a DSL connection), saturation of the uplink kills effective throughput for other TCPs (I presume because ACKs queue up at the router and are either delayed or timeout, resulting in fast retransmit if you're lucky, and a timeout at the sender if you're not).
> "does not slow down your internet connection" as it uses a "limited portion" of idle upload bandwidth."
How do Microsoft know what your upload bandwidth is? When do Microsoft know when that upload bandwidth is no longer idle?
Is there an RTT estimator that stops the upload if the RTT exceeds a threshold? How would Microsoft know what the RTT should be for that customers network link?
Perhaps they can detect consecutive timeouts of TCP segments? That would be interesting because the TCP I know provide the abstraction of a reliable, in order transmission over an unreliable network - so why would this API call exist? Perhaps it does exist? Can anyone comment?
I think this raises more questions that it answers?