Is the Slow-Start algorithm responsible for ISP speed throttling?

Question

I've been looking up how ISPs manage to cap a user's network speed given the theoretical limit of the infrastructure is usually much higher than the speed ISP's sell. I've stumbled across the TCP slow-start algorithm and it got me thinking that an ISP might kill a few ACKs to force the TCP stack into linear growth mode and eventually into near-zero growth once the contractual speed limit is reached.

Is my theory correct? If so, how do you limit an ACK-less protocol such as UDP?

Answer 1

Short answer: No, ISPs do not use TCP Slow-Start as the main way to throttle customer bandwidth.

---

Long answer: There are many ways that an ISP can throttle the bandwidth a particular customer gets allotted, but in my experience tweaking TCP knobs is very far down the list of possible methods. If you are an ISP, you can control the traffic volume at a lower network layer, (as opposed to controlling it via the specific behavior of ONE layer 4 protocol). It is usually cheaper and faster to munge about with traffic at layers 2 and 3, and so it makes more sense to do so there.

If you really want to learn more about this topic, I would recommend reading about Quality of Service (QOS). First, check out the Wikipedia Article on QOS and get a good grasp of the basic concepts and terminology.

Then, when you're ready to dive deeper, read the Cisco DocWiki article on QOS. This goes much deeper on the specific technologies and mechanisms of the QOS implementation on Cisco IOS.

Finally, if you want a really DENSE presentation with lots of good information about Service Provider QOS, read this wonderful presentation from Cisco: Optimizing the Service Provider Network for Voice, Video, and Data. However, depending on your current level of expertise, expect to do much Googling and learning related to the terms and technologies being used.

Answer 2

@Machinarius, @Brett Lykins has pretty much answered your question but without mentioning any techniques specifically.

If you wanted some further clarification then two main techniques very commonly used are shaping and policing depending on the service being contracted and the customer requirements. You will read about these in the links provided by @Brett Lykins.

To give you a simple practical example, let’s say our example customer takes a 10Mbps connection but the physical link can run at 100Mbps.

When using shaping, if the customer traffic tries to exceed 10Mbps, traffic starts to be queued up in a buffer (assume an infinite buffer size) and slowly let out at a rate no faster than 10Mbps. So what this means is that the customer doesn’t have any packet loss but their latency/RTT will increase because they are trying to send more traffic than they have been given, so it’s being queued up. Protocols like TCP will slow down the transmission speed as ACKs take longer to be send/received when traffic is being buffered without packet loss. However devices don’t have infinite amounts of RAM so there will be a point where even with shaping packet loss will occur because the buffers become full.

If you read through the links @Brett Lykins provided you will see that traffic can be classified and marked, then processed in accordance with a QoS policy such that “important” traffic coming in is less likely to be dropped than less important traffic when congestion occurs.

Policing or “rate-limiting” is just a case of setting a hard 10Mbps limit on the connection, if the traffic passing through tries to exceed this hard limit that then packets will be dropped according to whatever algorithm is in use as as WRED/RED/Tail-drop.

As above, when using policing one could set up multiple queues and split the 10Mbps allowance across different traffic priorities etc. The main difference to note is that policing is generally a hard limit while shaping will try to buffer traffic at the expense of RTT.