Re: Making tcp start transfers slow

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Patrick Petersen wrote:
Hey list
I have almost gotten my shaping setup up and running as planned. The
last barrier seems to be tcp overshooting availible bandwidth when its
starting a transfer, and thereby bursting the line, so ping rises for a
moment. At least this is my best guess at the problem :)

I sortof workaround this using the connbytes netfilter patch to make the first 80k of new connections go into a short queue limited to 1/3 - 1/2 of my downstream bandwidth. It works well in the case where the link is empty apart from a gamestream and someone is browsing "heavy .jpg" type web paged. It also helps a bit if there is other traffic - but if there are enough tcp connections on the go there will be higher latency bursts
caused by new connections as HTB can't throttle until it's a bit too late.



There is a possibility that its just plain old traffic being bursty for
some reason.. I am using bittorrent to test this, as it seems to be what
stresses the line the most.

Ahh bittorrent - this is a special case. It uses full duplex tcp - so may break some upstream shapers, you can assume that a fair number of your peers have flooded modem buffers - so there could be quite a few "unstoppable" packets headed your way. The worse thing about it, though is that it runs it's own algorithm on allready open tcps - so existing connections may go back into slowstart.


Would it be possible to lower the default window size, and thereby
making tcp start up slower, or would this just lower the overall speed?

It could help, but may also give you less of a share of a given uploaders bandwidth. Reducing MTU may also help (if you run BT on linux it may reduce rwin for you aswell).


My efforts so far can be seen here:
http://tc.schmakk.dk/betashaper

Had a quick look - Some thoughts:


I don't think you can catch all BT traffic by marking the BT ports, I see ipp2p - can you do it with this or maybe do per IP fairness for bulk traffic?

Be carefull about priorotising acks - don't all TCP packets after syn have ack set. Being lazy on a home setup I get away with giving small packets priority - saves alot of marking :-)

For ingress shaping - I find it nicer to shape per IP with htb and use esfq classic to get per tcp fairness rather than esfq on dst which is going to effectively make many bittorrent connections go into a FIFO, which could make for more burstiness.

Andy.




_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux