Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Jun 2010 20:54:44 +1000 (EST)
From:      Ian Smith <smithi@nimnet.asn.au>
To:        Olivier Nicole <Olivier.Nicole@cs.ait.ac.th>
Cc:        freebsd-questions@pp.dyndns.biz, freebsd-questions@freebsd.org, modulok@gmail.com
Subject:   Re: Online gaming and file downloads - latency hell!
Message-ID:  <20100621185459.N9227@sola.nimnet.asn.au>
In-Reply-To: <201006210559.o5L5xnL7016186@banyan.cs.ait.ac.th>
References:  <20100618120030.D6CA7106581D@hub.freebsd.org> <20100621134020.X9227@sola.nimnet.asn.au> <201006210559.o5L5xnL7016186@banyan.cs.ait.ac.th>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100621185459.N9227>