Messages in this thread | | | Date | Sun, 31 Aug 2003 17:44:50 +0200 | From | Andrea Arcangeli <> | Subject | Re: bandwidth for bkbits.net (good news) |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |