<br><br><div class="gmail_quote">On Sun, Feb 5, 2012 at 2:20 PM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div><div class="h5">On Sun, Feb 5, 2012 at 7:39 AM, Eric Dumazet <span dir="ltr"><<a href="mailto:eric.dumazet@gmail.com" target="_blank">eric.dumazet@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Le dimanche 05 février 2012 à 02:43 +0200, Jonathan Morton a écrit :<br>
<div>> On 5 Feb, 2012, at 2:24 am, George B. wrote:<br>
><br>
> > I have yet another question to ask: On a system where the vast<br>
> > majority of traffic is receive traffic, what can it really do to<br>
> > mitigate congestion? I send a click, I get a stream. There doesn't<br>
> > seem to be a lot I can do from my side to manage congestion in the<br>
> > remote server's transmit side of the link if I am an overall<br>
> receiver<br>
> > of traffic.<br>
> ><br>
> > If I am sending a bunch of traffic, sure, I can do a lot with queue<br>
> > management and early detection. But if I am receiving, it pretty<br>
> much<br>
> > just is what is and I have to play the stream that I am served.<br>
><br>
> There are two good things you can do.<br>
><br>
> 1) Pressure your ISP to implement managed queueing and ECN at the<br>
> head-end device, eg. DSLAM or cell-tower, and preferably at other<br>
> vulnerable points in their network too.<br>
<br>
</div>Yep, but unfortunately many servers (and clients) dont even<br>
initiate/accept ECN<br>
<div><br>
> 2) Implement TCP *receive* window management. This prevents the TCP<br>
> algorithm on the sending side from attempting to find the size of the<br>
> queues in the network. Search the list archives for "Blackpool" to<br>
> see my take on this technique in the form of a kernel patch. More<br>
> sophisticated algorithms are doubtless possible.<br>
><br>
</div>You can tweak max receiver window to be really small.<br>
<br>
# cat /proc/sys/net/ipv4/tcp_rmem<br>
4096 87380 4127616<br>
# echo "4096 16384 40000" >/proc/sys/net/ipv4/tcp_rmem<br>
<br>
A third one : Install an AQM on ingress side.<br>
<br>
Basically you can delay some flows, so that TCP acks are also delayed.<br>
<br>
Example of a basic tc script (probably too basic, but effective)<br>
<br>
ETH=eth0<br>
IFB=ifb0<br>
LOCALNETS="hard.coded.ip.addresseses/netmasks"<br>
# Put a limit a bit under real one, to 'own' the queue<br>
RATE="rate 7Mbit bandwidth 7Mbit maxburst 80 minburst 40"<br>
ALLOT="allot 8000" # Depending on how old is your kernel...<br>
<br></blockquote></div></div><div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><div>
A subtlety here is that several technologies in use today <br>(wireless-n, cable, green ethernet, GRO) are highly 'bursty',<br>and I'd regard minburst, maxburst as something that needs to be calculated as a respectable fraction of the underlying rate.<br>
<br> <br></div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
modprobe ifb<br>
ip link set dev $IFB up<br>
<br>
tc qdisc add dev $ETH ingress 2>/dev/null<br>
<br>
tc filter add dev $ETH parent ffff: \<br>
protocol ip u32 match u32 0 0 flowid 1:1 action mirred egress \<br>
redirect dev $IFB<br>
<br>
tc qdisc del dev $IFB root<br>
<br>
<br>
# Lets say our NIC is 100Mbit<br>
tc qdisc add dev $IFB root handle 1: cbq avpkt 1000 \<br>
rate 100Mbit bandwidth 100Mbit<br>
<br>
tc class add dev $IFB parent 1: classid 1:1 cbq allot 10000 \<br>
mpu 64 rate 100Mbit prio 1 \<br>
bandwidth 100Mbit maxburst 150 avpkt 1500 bounded<br>
<br>
# Class for traffic coming from Internet : limited to X Mbits<br>
tc class add dev $IFB parent 1:1 classid 1:11 \<br>
cbq $ALLOT mpu 64 \<br>
$RATE prio 2 \<br>
avpkt 1400 bounded<br>
<br>
tc qdisc add dev $IFB parent 1:11 handle 11: sfq<br>
<br>
<br>
# Traffic from machines in our LAN : no limit<br>
for privnet in $LOCALNETS<br>
do<br>
tc filter add dev $IFB parent 1: protocol ip prio 2 u32 \<br>
match ip src $privnet flowid 1:1<br>
done<br>
<br>
tc filter add dev $IFB parent 1: protocol ip prio 2 u32 \<br>
match ip protocol 0 0x00 flowid 1:11<br>
<div><div><br>
<br>
<br>
_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</div></div></blockquote></div></div></div><br><br clear="all"><div class="im HOEnZb"><br>-- <br>Dave Täht<br>SKYPE: davetaht<br></div><div class="HOEnZb"><div class="h5">US Tel: <a href="tel:1-239-829-5608" value="+12398295608" target="_blank">1-239-829-5608</a><br>
FR Tel: 0638645374<br><a href="http://www.bufferbloat.net" target="_blank">http://www.bufferbloat.net</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Dave Täht<br>SKYPE: davetaht<br>US Tel: 1-239-829-5608<br>FR Tel: 0638645374<br><a href="http://www.bufferbloat.net" target="_blank">http://www.bufferbloat.net</a><br>