Re: bandwidth for bkbits.net (good news)

[Andrea Arcangeli <andrea@suse.de>]

On Sun, Aug 31, 2003 at 04:31:32PM +0100, Alan Cox wrote:
> On Sul, 2003-08-31 at 15:45, Andrea Arcangeli wrote:
> > On Sun, Aug 31, 2003 at 02:15:12PM +0100, Alan Cox wrote:
> > > On Sul, 2003-08-31 at 03:56, Larry McVoy wrote:
> > > > I'm pretty convinced we can't solve the problem at our end.  Maybe we can
> > > 
> > > For bursts of traffic you can't.
> > 
> > what's the difference of rejecting packets in software, or because the
> > link can't handle them? Assume the guaranteed bandwidth is much lower
> 
> 
> It doesn't work when you dont control incoming. As a simple extreme
> example if I pingflood you from a fast site then no amount of shaping
> your end of the link will help, it has to be shaped at the ISP end.

sure, that's why I said it won't work with synflood. I just doubt the
ping/syn floods distributed denial of services are an high percentage of
the traffic passing through on bkbits.net. I though it was legitimate
traffic, and I assume bitkeeer is somehow efficient in handling the
transfer, by using a single tcp connection for the whole transfer of the
data, just like pserver/cvs-ssh do. For example if bitkeeper would open
a new tcp connection for each file (similar to cvsps -p -g w/o the
--cvs-direct option that I asked for), it would be much harder to shape
that traffic. But I understood the traffic that hurts is all in
established state for several seconds, so it should be technically
possible to stop it to around 1kbyte/sec globally to give an huge margin
to voip.

Andrea