[dangero]

Wow "Microsoft says that the feature “helps people get updates and apps more quickly if they have a limited or unreliable Internet connection” and “does not slow down your internet connection” as it uses a “limited portion” of idle upload bandwidth."

Sorry but Microsoft cannot know that. They can know how much bandwidth your machine has access to on some level, but they cannot know what kind of strain is being put on any shared router upstream including your home wifi router. It absolutely can slow down your internet. Maybe the author paraphrased Microsoft's response, but with that wording it's not accurate.

[arbitrage]

You actually can. Look into TCP slow start and backoff, congestion avoidance, etc.

https://en.wikipedia.org/wiki/TCP_congestion-avoidance_algor...

[georgerobinson]

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?

[wmf]

Microsoft has been working on something like that for years: https://en.wikipedia.org/wiki/Background_Intelligent_Transfe...

[dangero]

BITS uses client centric bandwidth measurement, not network centric which isn't really possible and that's the point of contention. You cannot know exactly how your network usage is affecting the larger network.

Basically Microsoft's response to concerns over the bandwidth usage is, "Well, the bandwidth was just sitting there not being used. Doesn't affect anything if we use it."

That's just not true and it's an oversimplification of network topology.

[dangero]

That does not solve it. A little technical response to your comment. The linked wikipedia page describes how TCP detects appropriate and safe bandwidth to use for transmission using 2 main techniques: 1. Detection of how long it takes to receive a round trip ACK message 2. Detection of dropped packets

Neither of those mechanisms guarantee that the client bandwidth has negligible effect on upstream data links or the bandwidth of other clients sharing those connections. The detection mechanisms are completely self focused on achieving the highest rate of transmission possible and correcting any changes to network reliability over time. They cannot create a reliable picture of overall bandwidth or the exact impact on other clients.

[lazzlazzlazz]

No, that's not at the correct level of abstraction. And even then - you may need that idle headroom for latency.