From owner-freebsd-questions@FreeBSD.ORG Mon Jun 21 10:54:54 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE7761065670 for ; Mon, 21 Jun 2010 10:54:54 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 4A9438FC12 for ; Mon, 21 Jun 2010 10:54:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o5LAsiRc077125; Mon, 21 Jun 2010 20:54:44 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 21 Jun 2010 20:54:44 +1000 (EST) From: Ian Smith To: Olivier Nicole In-Reply-To: <201006210559.o5L5xnL7016186@banyan.cs.ait.ac.th> Message-ID: <20100621185459.N9227@sola.nimnet.asn.au> References: <20100618120030.D6CA7106581D@hub.freebsd.org> <20100621134020.X9227@sola.nimnet.asn.au> <201006210559.o5L5xnL7016186@banyan.cs.ait.ac.th> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-questions@pp.dyndns.biz, freebsd-questions@freebsd.org, modulok@gmail.com Subject: Re: Online gaming and file downloads - latency hell! X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 10:54:55 -0000 On Mon, 21 Jun 2010, Olivier Nicole wrote: > Hi, > > > I've read about people trying > > to throttle outgoing ACKs to slow down their download but that still > > wouldn't rearrange any incoming data packets so I don't see how that > > would help. I haven't tried it myself though but neither have I read > > about anyone successfully accomplishing this. > > TCP uses a window: the maximum number of packects that you can receive > before you send an ACK. As long as ACK come flowing, the window size > increases. > > Limit the ACK, you limit/reduce the size of the window, so you > limit/reduce the incoming trafic. Indeed. If you've an in-house router queueing through traffic against some bandwidth limit imposed on an inside clients' download, dropping any excess TCP packets arriving on top of a full queue or pipe (eg with ipfw/dummynet), there'll be a few packets requiring retransmission to continue the transfer, now and again, without need to throttle ACKs; in fact we're expediting ACKs uphill, after streaming, ssh and ICMP. I've been surprised by how few packets get dropped and so resent, way less than 1%, even when pulling large files from fast providers through a slow link (512/512 ADSL as mentioned) then further limited to clients. Which are mostly 'doze, a mac or two, a couple of linux boxes; all seem to use SACK but I haven't looked into negotiated window sizes. I don't know TCP in any depth but watch with awe as people enhance and tune the stack; all I can say is 'it seems to mostly work pretty well here' .. How UDP-based services cope with dropped packets is another matter; perhaps that's a big issue for some games that may need expediting? > I beleive there could even be some nasty rewritting that would > artifically change the window size so the TCP stream is slowed down. Quite a job, intervening and rewriting packets, and maintaining state on whole streams; I gather TCP is resistant to Man in the Middle attack .. Anyway, a lot harder than configuring a few dummynet pipes and queues :) cheers, Ian