On Wed, Feb 19, 2003 at 05:02:29PM -0500, Greg A. Woods wrote:
> Well, if you're talking about them here, and if they don't seem to add
> up properly, then someone's probably going to tell you about it.  ;-)

Yeah, but you're the one who asked for a reason originally... the
question was about how to limit the number of connections/IP, not
whether it was a good idea or not. I'm just saying the reasons for
doing it have nothing to do with whether it's possible to do it or not.

> While it may be true that one person == one IP# for the tiny portion of
> the Internet that has accessed your machine to date, I wouldn't bet on
> it staying that way if I were you.

I'm not doing this on behalf of a company... it's a personal ftp site,
and the users are just random people on some mailing list I'm on. These
people may use NAT/firewalls/etc..., but even if so, the one person =
one IP still holds. They don't need to connect from 5 different machines
on their home LAN either :)

> Your test results are probably irrelevant -- your sole test environment
> cannot even come close to representing the wide variety of conditions
> that others commonly experience.  IIRC I have in the past regularly seen
> as much as 5% improvement in throughput.  There are lots of factors
> involved and every year there are still new research papers written
> about TCP's behaviour on this front.

True, it's a very limited test... but I think it reflects a pretty
common scenario. Anyways, isn't 6 seconds out of 107 or so a 5% to 6%
improvement? I'm not denying that you do get better speeds with
multiple connections. I'm not even saying that you won't get hugely
better speeds. What I'm saying is that in the case where you do get
hugely better speeds, it's because you're using an unfair portion of
the pipe.

> I think your reasoning is still flawed.  While I'm not an expert in
> queuing and operational theory, what knowledge I do have of it mirrors
> my real-world experiences, and together it all suggests that these
> issues are not nearly so clear-cut as you're trying to make them out to
> be.

Well, I'm no expert either... but I see people get 10K/sec while some
other guy with 8 connections going gets 80K/s or whatever, and when
I kill off the extra connections, things more or less even out. I
haven't collected TCP traces to analyze, but I think it's pretty clear
that absent packet loss, things do work basically as I've described
them.

A per IP limit isn't the solution for everyone, and it's not perfect,
but it's easy and works well enough that I'm happy with it.

> The problem is you cannot possibly ever force fair use in the general
> scenario without at least some minimal form of authentication that can
> identify "one person", and you can't do that by IP# alone, nor even by
> pairing it with the password given for anonymous users.

I realize that, but I also don't want to have to give out usernames
and passwords. I just want to send out a link and say "here, check this
out." (And I do say, "And don't use GetRight or DAP or any other
download accelerator", but some people don't listen :)

> Note also that an active FTP connection does not equal an active
> download.  Real human FTP users leave large gaps of unused bandwidth per
> connection, even when they're working through a caching proxy server.

I know that too... If a ftp server had a way of limiting RETR/STORs,
rather than connections, that'd be better.

> Finally also note that "fair use" from the user's perspective may not
> equate to a fair share of the available bandwidth at your end.  Some
> people might even argue that fair use from the user's perspective would
> be perceived more readily if you simply used "rateget guest 56k" (and
> allowed unlimited connections per client IP#).

Exactly what does NetBSD's ftpd's "rateget" mean? Doesn't "rateget guest
56k" limit the aggregate rate of all anonymous connections to
56kbytes/second? If so, that doesn't seem any different from the
situation where ftpd has no rate limit, and the limit is the bandwidth
of my net connection. Someone making multiple connections can get a
bigger share of that 56k. If the "rateget" means that _each_ anonymous
connection gets a max of 56kBps, that doesn't help either. Someone with
one connection will get 56kBps, but someone with two will get 102kBps.

> > I _am_ running a ftpd that can limit by IP, and empirical evidence shows
> > that I _have_ solved the problem.
> 
> Yes, but in the course of this discussion you've changed the definition
> of the problem you ar talking about, narrowing its scope considerably.
> In the new scope of this narrower problem you are not considering the
> general issues raised by the generic requirements you originally stated
> because now you are making assumptions that are not true in the general
> case.

Hmm, I don't think I've changed anything... In my original message, I
said, "instead of everyone getting 1/10th of my T1, the download 
accelerator guy will get 11/20ths of it, while the other 9 get 1/20th. 
This is obviously unfair for the well-behaved people." That's the same
as what I said in the message after that, just with different numbers.

But the bottom line is that limiting the number of connections/IP is 
quick and easy to do for some ftp servers (with ProFTPd, just put 
"MaxClientsPerHost n" in the conf file), and works well enough for me. 
As I mentioned in my previous message, I set the limit to 2, so one 
connection can be downloading while the other is used to browse the 
files. Of course, someone using a download accelerator will have both 
connections downloading, but it's better than them having 8 (or more) 
connections downloading. So unless someone wants to come up with a 
better scheme and set it up for me, I'll stick with my 2 connections/IP 
limit :)