3

I have tried to find the answer on how network throttling works e.g. by ISP when they limit your access to say 100 Mbps. As far as I know TCP/IP itself does not have any mechanisms for that, so it is probably something on top of the protocol that interferes with the packets.

My guess is that the packets received from the server are not sent directly to the client, but wait in some kind of throttling queue and the server does not send the next packet until the confirmation is received. I am not really a big expert on this, but would like to understand how this happens or maybe some good reference to how it works in simple terms, without too deep details (conceptual overview).

P.S. Not sure if throttling is protocol dependent, perhaps it's the same techniques that are used for others.

Improve this question

2 Answers 2

Reset to default
5

This really has nothing to do with TCP, or any other layer-4 protocol.

For the most part, this is done simply through policing (dropping) any inbound packets that would exceed the bandwidth limit. Outbound packets could be policed or shaped to a specific bandwidth. Shaping does use queues, but queues are finite and fairly small, not like the buffering you see for watching a video, and when a queue gets full, the traffic to be queued gets dropped. There are multiple shaping strategies. ISPs tend to want things simple, and most probably just use policing.

The whole QoS concept is far too large to explain in this site. There are entire books on QoS that have chapters on policing and shaping. You could do some further research on those concepts.

How each ISP does this type of thing may vary from ISP to ISP, and networks not under your control are off-topic here, so we can't tell you what any particular ISP does for this.

Improve this answer
7
  • Thank you for the answer. Could you please provide little bit more details on dropping of inbound packets? Would not that mean that the server would need to send the packet again using even more bandwidth?
    – Ilya Chernomordik
    Jan 26, 2017 at 7:49
  • I have no idea what is a client or server in this situation. The client/server model is an application model, and applications and protocols above OSI layer-4 are off-topic here. If a site sends traffic to an ISP, the traffic is inbound to the ISP, and the ISP can drop the traffic there and not use bandwidth for which it pays when connecting to other ISPs. A typical ISP has far more customer bandwidth available and in-use than it has between it and the other ISPs of the Internet. That is oversubscription.
    – Ron Maupin ♦
    Jan 26, 2017 at 14:44
  • I am just trying to understand what happens when inbound packages are dropped as you described, that's why I used the word server, but I suppose inbound traffic is more correct to use here.
    – Ilya Chernomordik
    Jan 27, 2017 at 9:31
  • @crrimson, this is about ISP throttling, and the ISPs throttle traffic across the board, not by transport protocol. Yes, you can run QoS and throttle by transport protocol, but ISPs do not; they throttle all your traffic.
    – Ron Maupin ♦
    May 12, 2018 at 0:03
  • While I agree for the most part, I disagree with this statement: "This really has nothing to do with TCP, or any other layer-4 protocol." A) One method of rate-limiting that could be employed by a web proxy would be to lower the TCP window size on one side of a TCP conversation, thus limiting the transfer rate. B) QoS policies which you mention but don't explain would typically use an ACL to match certain traffic types (ie: TCP port 80/443), and then place those specific types into a specific queue, which depending on the policy configuration may be more likely to be dropped or policed.
    – crrimson
    May 12, 2018 at 0:04
1

Regarding the dropping of packages; this effectively means more bandwidth usage. But, and this is a big but, TCP realizes the network is dropping packages and slows down. It has algorithms which try to use the maximum bandwidth possible while keeping communication reliable.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.