fixing TCP buffers (Re: packet reordering at exchange points)

E.B. Dreger eddy+public+spam at noc.everquick.net
Wed Apr 10 01:27:25 UTC 2002


> Date: Tue, 9 Apr 2002 21:12:30 -0400
> From: Richard A Steenbergen <ras at e-gerbil.net>


> That doesn't prevent an intentional local DoS though.

And the current stacks do?  (Note that my 64 kB figure was an
example, for an example system that had 512 current connections.)

Okay, how about new sockets split "excess" buffer space, subject
to certain minimum size restrictions?  New sockets do not impact
establish streams, unless we have way too many sockets or too
little buffer space.

If way too many sockets, it's just like current stacks, although
hopefully ulimit would prevent this scenario.

If we're out of buffer space, then we're going to have even more
problems when the sockets are actually passing data.

Yes, I'm still thinking about carving up a 32 MB chunk of RAM,
shrinking window sizes when we need more buffers.

Of course, we probably should consider AIO, too... if we can
have buffers in userspace instead of copying from kernel to
user via read(), that makes memory issues a bit more pleasant.


--
Eddy

Brotsman & Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist at brics.com>
To: blacklist at brics.com
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <blacklist at brics.com>, or you are likely to
be blocked.




More information about the NANOG mailing list