What the hell is "tcp_rate_limiting"

[Odos]

Hiya all, as the subject line, can anyone tell me what tcp_rate_limiting actually is ?

I was checking my router logs and according to them I have had 517 tcp_rate_limiting attacks. I've tried googling the term but all the results I get ( the ones in English anyway ) state that, and I quote " It's to do with security " 

I'm not concerned about it, just curious as I is nosey 

Cheers

[Rik]

No idea, Tony, but I'm hoping to find out.

[kinmel]

Are you sure you want to know......................


TCP Rate Limiting and Window Manipulation

The Packeteer PacketShaper's primary "technology" is TCP rate limiting, which is a technique that "paces" traffic by "faking out" the transmitter by artificially changing the TCP window and pacing ACKs, effectively throttling the traffic. This works well (on TCP traffic only), however the effects of it can be undesireable when used as a primary means of achieving bandwidth management results. There are several fundamental problems with this technology:

First, there is an adaptation period for each session, as the initial window is usually set to be quite large, and most sessions are quite short. The "pace" required for any particular session is not constant. For example to achieve 512kbs on your local network would require a much longer delay and much smaller window than if the client was 20 hops away. Additionally, since traffic on a busy network (lets talk about ISP's here) changes on a moment to moment basis, the window size required to get the proper management will change more rapidly than the devices ability to change all of the windows for all of the sessions that it is managing. Every time your browser clicks a new page, a new session is created generally. It is difficult and inefficient to control these sessions by window manipulation, because they are so short-lived in nature.

The second issue has to do with resources and overhead. With TCP rate limiting each "session" (that is each TCP connection) must be managed individually. Each stream must be monitored, ACKs must be delayed, and packet headers must be rebuilt. This is why devices that heavily utilize TCP rate limiting on every individual traffic stream have much lower capacities in terms of being able to handle traffic loads than other available technologies.

Another problem is that if you try to rate-limit with windows smaller than one full packet, the result is more packets and more traffic on your network. Typically this is so undesireable that its not done. Window sizes of one full packet (typically 1500 bytes) is the minimum that can be used without creating additional network overhead.

Next, and most importantly, session "pacing" by itself doesn't achieve the desired result. Since an end user can have any number of simultaneous sessions, you can't limit a user to a fair "chunk", which is usually whats needed. A browser, for example, can open any number of tcp sessions to the same location, so pacing each session to 128K will not limit the user in the desired way; he will be able to use N times 128k depending on how many sessions he has open at the time.

Lastly, TCP rate limiting doesn't work at all on encrypted data, because the TCP header is hidden from the bandwidth management device. As IPsec becomes utilized more and more, the effectiveness of TCP rate limiting will dwindle proportionately.

Well, after that you may deduce that window manipulation doesn't have any value at all. On the contrary. We have found that TCP window manipulation as a peripheral function is highly effective in "shaping" traffic and reducing the amount of traffic that needs to be queued and managed. The ET/BWMGR uses TCP window manipulation as a fundamental mechanism to reduce flows and improve overall network performance through your network. As an example, consider the following:

Suppose you have a T1 line and a single server. Suppose that 2 remote clients request the same page simultaneously, and that page has 15,000 bytes of information. With a typical TCP window of 16K, the entire page will be sent without requiring an ACK from the client. So as soon as the requests are received, 30,000 bytes of data are sent from the server to your router's queue. At T1 speeds, 193 bytes per millisecond can be transmitted, which means that it will take 155 milliseconds to empty the queue. Any other traffic that is being sent by your network will have to wait until this traffic is sent. So you have over 150ms of latecy in your network at this moment in time.

Now assume that you have a bandwidth management device which is window shaping and it announces a window of 3000 to your server. Now the server can only send out 6000 bytes of data in response to the requests, which will only take 31 milliseconds to transmit. You have cut your network latency by 124ms without any hard limits.

Of course most pages aren't so large, but you also often have more than 2 connections on your network, so the effect is similar. What is important to understand is that bandwidth management devices which do not utilize window manipulation at all cannot reduce your network latency on an overall basis. They will simply shift the latency from one type of traffic to another.


So that's it, in a nutshell 

[Rik]

Must have been a coconut, Alan.

[Inactive]

 

[somanyholes]

if you have the option, i would be tempted to turn it off. I suppose you could liken the affects of what it's doing as the same as the windows update that try's to limit your tcp connections.

Are you using bit torrent by any chance?

do you use voip?

[Odos]

Thanks for the replies, sorry took so long to respond, I've been at work.

To start with I was clueless. Now I'm clueless and confused.   I must be either missing something or not understanding what I'm being told.

After reading Alans post I would take it that "tcp_rate_limiting" is a function that a network manager uses to control his network traffic and yet my router class's it as a method of attack. The header on the logs page on which that entry appeared states " The table shows the number of times the SpeedTouch actively protected your network against each intrusion since last statistics reset. "

somanyholes : No I never ever use torrents or voip.

As I said to begin with it's not a problem, I was just trying to understand what it was about is all.

Cheers

[Sebby]

I had a search on Google, but there doesn't really seem to be anything much about this. What I'd say is that the firewall is doing its job and you can most probably safely forget about it.

[drummer]

I came across this when my ISP was Tiswas as I was interested in what traffic shaping actually meant.

Purely from my dysfunctional memory, I think it's a generic term that applies to the blocking/management of web traffic, including mundane things like ping requests.

If I wasn't about to nod off, I'd use "rate limiting" to do a search.

[somanyholes]

Here is my attempt to explain what rate limiting is.

So what is a connection?

In it's simplest form it's the following.

your computer wants to connect to a webserver and it does the following.

it sends a synchronize (syn) packet to the webserver basically saying i want to talk to you
the webserver sends a acknowledge (ack) packet back to say yes i acknowledge that I received the syn packet and i will talk to you.
the  computer then sends a synchronize acknowledge (syn,ack) packet back to the webserver to complete the connection. This is called the three way handshake.

So we know now what syn, ack and syn,ack packets are.

So what your router is doing is trying to control the amount of these connections/syn's/acks going through your router by controlling the flow of syn/ack packets. The router will have a setting which defines how many syn/ack packets are acceptable per connection.

So why does it do this.

There are probably many reasons but the main ones are.

1. Security protection, it can help against dos/ddos attacks. These create many connections that try to create a denial of service. I.e. slowing down your internet or stopping webservices etc.

2. Bandwidth management. Services such as voip require a certain amount of bandwidth to function correctly, the rate limiting stops one service or services from hogging all the bandwidth.

So the alerts you are seeing are due to the fact that something is commnicating through your router and the router does not like the amount of packets it is seeing and is therefore slowing down/controlling these connections.

The above is a vague descrioption, bandwidth management is also used by qos etc.

Hopefully it makes a bit more sense.

http://www.youtube.com/watch?v=RbY8Hb6abbg&feature=related
http://en.wikipedia.org/wiki/Transmission_Control_Protocol

[kinmel]

thanks for a sensible explanation 

[Rik]

Karmic explanation, So. 

[Odos]

Thanks for the explanation, I think I understand it now 

Cheers