Hi,

I am having a problem where ftp traffic is flooding the ethernet interface 
and other processes on the recipient machine can't get their traffic on the 
network. I was thinking of lowering the priority on inetd on the recipient 
machine, but I wanted to know if I can limit ftp transfer rate on the 
server. There is a tunable for ethernet called pace_size. Is this the way to 
limit traffic?

Thanks,
JS 

"John Smith" <john_smith274@microsoft.com> writes:

> Hi,
> 
> I am having a problem where ftp traffic is flooding the ethernet interface 
> and other processes on the recipient machine can't get their traffic on the 
> network. I was thinking of lowering the priority on inetd on the recipient 
> machine, but I wanted to know if I can limit ftp transfer rate on the 
> server. There is a tunable for ethernet called pace_size. Is this the way to 
> limit traffic?

You might try configuring ipqos to condition the ftp transfers- it works
pretty well for tcp traffic.  You can condition the both transmit and
receive traffic flows.  At first glance it seems wasteful to discard at
the receiver, but what you're trying to do is drop traffic such that the
TCP sender slows down until the traffic is no longer dropped- so it
doesn't really matter where you do it.

Lowering the task priority won't buy you much, it doesn't take much cpu
time to saturate a typical lan drop and anyhow you'd need other tasks on
machine competing for cpu time.  If the machine is otherwise more or
less idle, the ftp client or daemon will get all the cpu time it wants
anyhow.

docs.sun.com documents ipqos, man ipqos is also available.

Gregm

John Smith wrote:
> Hi,
> 
> I am having a problem where ftp traffic is flooding the ethernet interface 
> and other processes on the recipient machine can't get their traffic on the 
> network. I was thinking of lowering the priority on inetd on the recipient 
> machine, but I wanted to know if I can limit ftp transfer rate on the 
> server. There is a tunable for ethernet called pace_size. Is this the way to 
> limit traffic?
> 

Try a different ftp server.

proftpd
ncftpd
vsftpd

all do bandwidth limiting.

regards,

Mark

In article <m3d5sfaa6f.fsf@athena.pienet>,
	Greg Menke <gregm-news@toadmail.com> writes:
> "John Smith" <john_smith274@microsoft.com> writes:
>> Hi,
>> 
>> I am having a problem where ftp traffic is flooding the ethernet interface 
>> and other processes on the recipient machine can't get their traffic on the 
>> network. I was thinking of lowering the priority on inetd on the recipient 
>> machine, but I wanted to know if I can limit ftp transfer rate on the 
>> server. There is a tunable for ethernet called pace_size. Is this the way to 
>> limit traffic?
> 
> You might try configuring ipqos to condition the ftp transfers- it works
> pretty well for tcp traffic.  You can condition the both transmit and
> receive traffic flows.  At first glance it seems wasteful to discard at
> the receiver, but what you're trying to do is drop traffic such that the
> TCP sender slows down until the traffic is no longer dropped- so it
> doesn't really matter where you do it.

This is harder than you might imagine because ftp data transfers
are not on fixed port numbers, which can make writing a rule to
identify that particular traffic flow (as distinct from anything
else) rather difficult.

-- 
Andrew Gabriel

andrew@cucumber.demon.co.uk (Andrew Gabriel) writes:

> In article <m3d5sfaa6f.fsf@athena.pienet>,
> 	Greg Menke <gregm-news@toadmail.com> writes:
> > "John Smith" <john_smith274@microsoft.com> writes:
> >> Hi,
> >> 
> >> I am having a problem where ftp traffic is flooding the ethernet interface 
> >> and other processes on the recipient machine can't get their traffic on the 
> >> network. I was thinking of lowering the priority on inetd on the recipient 
> >> machine, but I wanted to know if I can limit ftp transfer rate on the 
> >> server. There is a tunable for ethernet called pace_size. Is this the way to 
> >> limit traffic?
> > 
> > You might try configuring ipqos to condition the ftp transfers- it works
> > pretty well for tcp traffic.  You can condition the both transmit and
> > receive traffic flows.  At first glance it seems wasteful to discard at
> > the receiver, but what you're trying to do is drop traffic such that the
> > TCP sender slows down until the traffic is no longer dropped- so it
> > doesn't really matter where you do it.
> 
> This is harder than you might imagine because ftp data transfers
> are not on fixed port numbers, which can make writing a rule to
> identify that particular traffic flow (as distinct from anything
> else) rather difficult.

Isn't one end of the data transfer going to be on tcp port 20?  Now with
rpc stuff I agree, trying to keep ipf from snarfing up rpc/nfs traffic
that is shouldn't is a PITA.

Gregm

In article <m3fyxa522o.fsf@athena.pienet>,
	Greg Menke <gregm-news@toadmail.com> writes:
> andrew@cucumber.demon.co.uk (Andrew Gabriel) writes:
> 
>> In article <m3d5sfaa6f.fsf@athena.pienet>,
>> 	Greg Menke <gregm-news@toadmail.com> writes:
>> > You might try configuring ipqos to condition the ftp transfers- it works
>> > pretty well for tcp traffic.  You can condition the both transmit and
>> > receive traffic flows.  At first glance it seems wasteful to discard at
>> > the receiver, but what you're trying to do is drop traffic such that the
>> > TCP sender slows down until the traffic is no longer dropped- so it
>> > doesn't really matter where you do it.
>> 
>> This is harder than you might imagine because ftp data transfers
>> are not on fixed port numbers, which can make writing a rule to
>> identify that particular traffic flow (as distinct from anything
>> else) rather difficult.
> 
> Isn't one end of the data transfer going to be on tcp port 20?  Now with

All current clients would normally use PORT or PASV commands
(or more recent replacements), which override the use of port 20.
If you do drop back to using port 20, then you can't transfer a
second file without waiting for the 2MSL TCP timer to expire (or
using a different transfer mode which allows data connection reuse,
but this isn't normal, and I doubt if current implementation even
support it any more).

> rpc stuff I agree, trying to keep ipf from snarfing up rpc/nfs traffic
> that is shouldn't is a PITA.

To properly handle ftp data connections in this IPQoS architecture,
you need a state machine spying on the control connection and
setting up appropriate temporary filters to catch the data
connections for their duration.

-- 
Andrew Gabriel