Online gaming and file downloads - latency hell!
smithi at nimnet.asn.au
Mon Jun 21 10:54:55 UTC 2010
On Mon, 21 Jun 2010, Olivier Nicole wrote:
> > 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
> 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 :)
More information about the freebsd-questions