On Thursday 23 March 2006 03:31, David S. Miller wrote:
> From: John Heffner <[EMAIL PROTECTED]>
> Date: Wed, 22 Mar 2006 23:38:25 -0500
>
> > Given the relatively widespread availability of 100 Mbps or greater
> > connectivity on college campuses and larger companies, and the increasing
> > availability of fiber to the home (especially in places like S. Korea and
> > Japan), I'd really like to see the default buffer sizes increased
> > significantly. I'm thinking something like 4 MB would be a good number.
> > (This number should probably be automatically chosen at boot time, so
> > that it's not more than ~1-2% of total system memory.) This would give
> > 100 Mbps on a transcontinental link, but isn't an unreasonable amount of
> > memory for most systems.
>
> I thought the current settings were good enough for a 100Mbps
> transcontinental link? Or am I thinking 10Mbps?
It's good enough for about 5 Mbps across the US. BTW, I actually meant to say
"intercontinental" above. I have about a 270 ms RTT to Austrailia, which
would give me a max of ~2 Mbps. This is an order of magnitude too small for
the average user on a college campus, and two orders of magnitude too small
for the high end. The high end people can probably do some sysctl tweaking,
but I would be much happier if "just worked" for the average campus user.
> Increasing these limits so much is not a good idea, all I need to do
> is find a host which is willing to not sink any further TCP data I
> send to it at the point in time I tell it to, and I can thus ramp up
> the congestion window enough then consume 4MB of unswappable kernel
> memory times the number of sockets I can open up. Not good.
>
> And increasing the per-socket limit make it easier for a malicious user
> to take a large portion away from the global TCP memory pool, and thus
> put everyone into contrained memory allocation mode. Also not good.
I'm trying to argue that it's more effective for an attacker to just create
new connections, rather than inflate one existing connection. I can think of
applications unlike web server, which aren't willing to open a large number
of connections. However, to deal with this case, it seems sufficient to
limit a single connection to a small fraction (I suggested 1-2%) of available
memory. On most machines today with several hundred MB, a couple MB isn't so
bad.
For a web server to properly defend against this type of attack, it must be
able to kill off dead connections, regardless of the maximum individual
socket size.
> Responsibly allowing applications to chew up large amounts of global
> resources requires being able to take those resources away. With
> virtual memory, we can swap the dirty pages out to disk, but with a
> TCP sender something external controls whether we can liberate the
> data or not. This is why we must use sane per-socket limits in order
> to prevent dangerous situations like the one's above.
Right. The point though is that there is no (such small) limit on many small
connections, which could easily consume an equal amount of memory as one
larger connection.
> I do agree that the values should scale with the amount of memory.
> And that we do right now, but it could definitely be better. All
> 3 array entries in each of tcp_{,r,w}mem[] should be expressed as
> a percentage of main memory, and tcp_init() should just init them
> up by applying those percentages to num_physpages.
>
> The key point is to keep the per-socket limits far enough away from
> the global pool limits such that it is not easy for a single entity
> to maliciously put the allocator into conservative mode and penalize
> the legitimate users.
>
> What do you think?
How about something like max(64k, min(4M, tcp_mem[2]*PAGE_SIZE/100))?
Thanks,
-John
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
