Hi Nico, 90% of the bandwidth hogs we see are folks using well-behaved OSs. And for the evil-doers out there that decide to craft a special mass-mailer that somehow bypasses their OS TCP stack to ignore the window size, then there's nothing to do there but use standard QoS drops. But that's a rare occurrence. The more common issue are impolite clients that need to be elegantly shaped down.
-J On 2/21/07, Nicolas Williams <[EMAIL PROTECTED]> wrote:
On Wed, Feb 21, 2007 at 02:37:34PM -0700, Jason J. W. Williams wrote: > >I'm not sure that I understand what you're talking about here, > >can you expand on what problem you're having and how you would > >like to address it? > > Say for example you've got a heavily utilized SMTP server. 100 > different clients connect that you haven't seen before. 20 of them > start transmitting 20 MB files concurrently, which completely > saturates your 20 Mb/s link for 106 seconds (assuming each client is > limited on their end to a T1). In this case, what I'd like to be able > to do is tell the OS when the connection is built up only allow this > sender to consume 100 Kb/s. If the after 3 MB they're still sending > data then I'd want to ratchet them down again to probably 20 Kb/s. The > reason being, these 10 senders otherwise prevent the other 80 from > getting connections...or cause them to time out. But you don't need to muck with the MSS to make this happen -- nor can you since it's a connection establishment-time thing. It's important to note that you can't actually stop bad peers from sending packets at their line rate, but you can slow down well behaved peers. Nico --
_______________________________________________ networking-discuss mailing list [email protected]
