[ On Wednesday, February 19, 2003 at 15:25:18 (-0600), Dave Huang wrote: ]
> Subject: Re: FTPD: disallowing concurrent connections from same IP
>
> It's my server, and I get to decide how people connect to it--I really
> need no justification.

Absolutely.  No disagreement about that part!

> Which is why my reasons are actually quite
> unimportant.

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.  ;-)

> > Secondly note that IP# != person.
> 
> While true in general, not true in my case. I have server logs and know 
> my user base. The majority of connections are from obviously 
> single-user machines... From your postings to the lists, I gather that
> you're an old-timer--I know multiuser timeshare type systems were all 
> there was back in the day, but today, the vast majority of systems on 
> the internet are single-user machines.

Sorry, but that's just not true for vast quantities of the Internet, and
it has nothing whatsoever to do with multi-user systems or timesharing.
However it does have everything to do with caching gatways, proxies, and
NATs, firewalls, etc.; things which are quite prevalent in all sectors
of the global public Internet today.

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.

> Only marginally better throughput--a percent or two improvement isn't
> significant to me.

You're not the persons doing the downloads though!  :-)

> As a test, I downloaded a 16 meg file with one
> connection in 1:47. With 2 simultaneous connections, it took 1:41;
> and with 3, 1:41. Yay. This is to a machine with an OC3 (and more)
> to the rest of the net, so there's no bottleneck at that end.

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.

> And
> multiple connections has a huge adverse effect on users who only have 
> one connection open. Which is _the_ reason I like to limit the number 
> of connections/IP... you haven't addressed that issue at all. Better
> throughput for one person at the expense of others is bad.

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.

> Right--I don't care how long people stay connected, and they can use
> as much of my bandwidth as they want _as long as they're fair to other
> users_. To reiterate, I want 5 people to each get 1/5th of the bandwidth.
> I don't want one person to get 6/10ths of the bandwidth and the other 4
> to get 1/10th each. It's all about being fair... if people don't want
> to be fair out of the goodness of their hearts, well I'm gonna force
> them to be fair, at least when it comes to my ftp server.

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.

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.

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#).

> 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.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>