Stop one user from using all Bandwidth? Traffic Shape?

None that I am aware of. What you want is usually found in routers.

Regards, Christoph Gartmann

Looks like my PIX Supports those commands, though I'm not sure how to impliment them in my case. They are doing priority for voice traffic. I guess It is a start..

Thanks!

Scott

By virtue of the way TCP/IP works, one user can't use all the bandwidth. They can make things slower because you have maxed out the available bandwidth, but other flows will take bandwidth from the high bandwidth flow. On a congested pipe (as you have when a user is doing a big FTP transfer), the pipe will start to drop packets, and when a TCP packet is dropped, the flow rate (bandwidth) of that TCP flow is cut in HALF. Now if you have one flow using 2 MB/s and 10 others using the other 1 MB/s, odds are 1 out of every 2 dropped packets will come from the 2MB/s flow. As soon as the first packet is dropped, the flow rate of the 2MB/s flow will be cut to 1MB/s (beause the window size is cut in half). TCP increases the window size by one MTU (or one packet) each time that an ACK is received and the window is not full. This is alsotrue of every other flow, so the other TCP flows can increase their bandwidth usage as well. In the real world, this can make HTTP traffic very slow because web pages are small and the ramp up in the flows is relatively slow.

Your best option here is to implement QoS and put FTP traffic in lower queue than your other traffic. In this fashion you can rate-limit the FTP traffic when there is congestion, but allow it to use as much bandwidth as it can if other traffic isn't using the pipe. I've never used a PIX so I don't know if they have this capability or if it does, how to configure it. Basically QoS will start to drop packets from the lower queues before the pipe is full, so you still have bandwidth available to the higher priority queues.

I would think that in this case, where you don't want to limit traffic of a certain class but only need to give everyone fair share of the limited bandwidth, the use of "(weighted) fair queuing" is much more suitable.

As already observed TCP is very good at apportioning the bandwidth between competing streams. This was what it was designed to do.

The file transfer method has not been mentioned. Some systems deliberately work round the TCP fair sharing system by either using multiple TCP streams or UDP. I believe that some FTP clients use multiple streams, and of course the modern p2p software does multiple streams and UDP too. In the latter case you could try to block the UDP. For the case where multiple TCP streams are in use you will either need fancy firewall software (no idea if any exists) or ask them nicely to desist.

For example MS Exchange by default used up to

10,000 TCP sessions to send mail. One mail server I had to troubleshoot was used to send mailsots to a few hundred people. This totally filled the DSL internet link such that nothing worked, not even the mailshot. Of course almost no one *needs* that many sessions so we used to set it to 3 or 5.

Is it possible to limit the number of concurrent TCP connections per host [or host + dest port] on ASA [or IOS]?

I agree with Rob. A big problem that occurs is fair allocation of the bandwidth, and, the issue of global synchronization from interface-level packet drop. WFQ and WRED would be good options, but I don't believe either is implemented on the PIX. I'd look at a traffic shaping device (specialized appliance or router) that allows you to implement a global traffic policy. WFQ will help with flow starvation, and WRED will address global sync issues.

Since this is an Internet pipe, I'd consider the appliance approach. Some appliances out there manipulate the TCP parameters, perform UDP shaping via buffering, ACK pacing, and such...a little more "creative" than a straight MQC Cisco router policy.

Rob wrote:

WFQ is just one of several queue management methods that you can also use with QoS. QoS is only in affect when the bandwidth on the pipe reaches around 80% utilization. When applying bandwidth to the various queues, only the priority queue (of which there can only be one) has reserved bandwidth. The other queues only specify the minimum bandwidth available to each queue. QoS starts managing the drops of the various types of traffic just before the pipe is congested and does this in a way so that higher priority traffic has bandwidth at the expense of lower priority traffic before the pipe is congested. If the pipe is 100% congested it applies a more refined approach than dropping traffic at random.

I'm curoius to know how effective that shaping is, being that traffic in the download direction shaping shouldn't be done at the provider level to be really effective? Bye, Tosh.