Le dimanche 05 février 2012 à 02:43 +0200, Jonathan Morton a écrit :
> On 5 Feb, 2012, at 2:24 am, George B. wrote:
>
> > I have yet another question to ask: On a system where the vast
> > majority of traffic is receive traffic, what can it really do to
> > mitigate congestion? I send a click, I get a stream. There doesn't
> > seem to be a lot I can do from my side to manage congestion in the
> > remote server's transmit side of the link if I am an overall
> receiver
> > of traffic.
> >
> > If I am sending a bunch of traffic, sure, I can do a lot with queue
> > management and early detection. But if I am receiving, it pretty
> much
> > just is what is and I have to play the stream that I am served.
>
> There are two good things you can do.
>
> 1) Pressure your ISP to implement managed queueing and ECN at the
> head-end device, eg. DSLAM or cell-tower, and preferably at other
> vulnerable points in their network too.
Yep, but unfortunately many servers (and clients) dont even
initiate/accept ECN
> 2) Implement TCP *receive* window management. This prevents the TCP
> algorithm on the sending side from attempting to find the size of the
> queues in the network. Search the list archives for "Blackpool" to
> see my take on this technique in the form of a kernel patch. More
> sophisticated algorithms are doubtless possible.
>
You can tweak max receiver window to be really small.
# cat /proc/sys/net/ipv4/tcp_rmem
4096 87380 4127616
# echo "4096 16384 40000" >/proc/sys/net/ipv4/tcp_rmem
A third one : Install an AQM on ingress side.
Basically you can delay some flows, so that TCP acks are also delayed.
Example of a basic tc script (probably too basic, but effective)
ETH=eth0
IFB=ifb0
LOCALNETS="hard.coded.ip.addresseses/netmasks"
# Put a limit a bit under real one, to 'own' the queue
RATE="rate 7Mbit bandwidth 7Mbit maxburst 80 minburst 40"
ALLOT="allot 8000" # Depending on how old is your kernel...