From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 86CC5200627 for ; Sun, 5 Feb 2012 06:24:19 -0800 (PST) Received: by werb14 with SMTP id b14so6602096wer.16 for ; Sun, 05 Feb 2012 06:24:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7buXVqS5UCbq1a1bmBgejrBM6oWIKV+RJPgzoF0yI1E=; b=EPXcT7hsHYtM95S0sx0Wgiym+tQGMaK/fNN+NV58PkPlI3wxFS0WRfQ06Nvi+y80Fy 9BcQvA8L10I10uYS+AQdiOFXd2+ftEU2gkQeZnJZ7eaqNZA0WyqGLqkj7wIRtRPmlODC 9sug4KcKKm/1tt4Yz7jN4mXUWzkxMbuw3ZKSE= MIME-Version: 1.0 Received: by 10.216.145.1 with SMTP id o1mr2016737wej.45.1328451856143; Sun, 05 Feb 2012 06:24:16 -0800 (PST) Received: by 10.223.72.1 with HTTP; Sun, 5 Feb 2012 06:24:16 -0800 (PST) In-Reply-To: References: <1325481751.2526.23.camel@edumazet-laptop> <4F046F7B.6030905@freedesktop.org> <40C8C302-7B23-4272-8322-1D916BB0CEB2@gmail.com> <1328427596.14474.9.camel@edumazet-laptop> Date: Sun, 5 Feb 2012 14:24:16 +0000 Message-ID: From: Dave Taht To: Eric Dumazet Content-Type: multipart/alternative; boundary=0016e6d62550fc975e04b8384cd4 Cc: bloat Subject: Re: [Bloat] What is fairness, anyway? was: Re: finally... winning on wired! X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 14:24:20 -0000 --0016e6d62550fc975e04b8384cd4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Feb 5, 2012 at 2:20 PM, Dave Taht wrote: > > > On Sun, Feb 5, 2012 at 7:39 AM, Eric Dumazet wrot= e: > >> Le dimanche 05 f=E9vrier 2012 =E0 02:43 +0200, Jonathan Morton a =E9crit= : >> > 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=3Deth0 >> IFB=3Difb0 >> LOCALNETS=3D"hard.coded.ip.addresseses/netmasks" >> # Put a limit a bit under real one, to 'own' the queue >> RATE=3D"rate 7Mbit bandwidth 7Mbit maxburst 80 minburst 40" >> ALLOT=3D"allot 8000" # Depending on how old is your kernel... >> >> > A subtlety here is that several technologies in use today > (wireless-n, cable, green ethernet, GRO) are highly 'bursty', > and I'd regard minburst, maxburst as something that needs to be calculate= d > as a respectable fraction of the underlying rate. > > > >> modprobe ifb >> ip link set dev $IFB up >> >> tc qdisc add dev $ETH ingress 2>/dev/null >> >> tc filter add dev $ETH parent ffff: \ >> protocol ip u32 match u32 0 0 flowid 1:1 action mirred egress \ >> redirect dev $IFB >> >> tc qdisc del dev $IFB root >> >> >> # Lets say our NIC is 100Mbit >> tc qdisc add dev $IFB root handle 1: cbq avpkt 1000 \ >> rate 100Mbit bandwidth 100Mbit >> >> tc class add dev $IFB parent 1: classid 1:1 cbq allot 10000 \ >> mpu 64 rate 100Mbit prio 1 \ >> bandwidth 100Mbit maxburst 150 avpkt 1500 bounded >> >> # Class for traffic coming from Internet : limited to X Mbits >> tc class add dev $IFB parent 1:1 classid 1:11 \ >> cbq $ALLOT mpu 64 \ >> $RATE prio 2 \ >> avpkt 1400 bounded >> >> tc qdisc add dev $IFB parent 1:11 handle 11: sfq >> >> >> # Traffic from machines in our LAN : no limit >> for privnet in $LOCALNETS >> do >> tc filter add dev $IFB parent 1: protocol ip prio 2 u32 \ >> match ip src $privnet flowid 1:1 >> done >> >> tc filter add dev $IFB parent 1: protocol ip prio 2 u32 \ >> match ip protocol 0 0x00 flowid 1:11 >> >> >> >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >> > > > > -- > Dave T=E4ht > SKYPE: davetaht > US Tel: 1-239-829-5608 > FR Tel: 0638645374 > http://www.bufferbloat.net > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net --0016e6d62550fc975e04b8384cd4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Feb 5, 2012 at 2:20 PM, Dave Tah= t <dave.taht@gm= ail.com> wrote:


On Sun, Feb 5, 20= 12 at 7:39 AM, Eric Dumazet <eric.dumazet@gmail.com> wr= ote:
Le dimanche 05 f=E9vrier 2012 =E0 02:43 +0200, Jonathan Morton a =E9crit :<= br>
> On 5 Feb, 2012, at 2:24 am, George B. wrote:
>
> > I have yet another question to ask: =A0On a system where the vast=
> > majority of traffic is receive traffic, what can it really do to<= br> > > mitigate congestion? =A0I send a click, I get a stream. =A0There = doesn't
> > seem to be a lot I can do from my side to manage congestion in th= e
> > remote server's transmit side of the link if I am an overall<= br> > receiver
> > of traffic.
> >
> > If I am sending a bunch of traffic, sure, I can do a lot with que= ue
> > management and early detection. =A0But if I am receiving, it pret= ty
> 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. =A0This prevents the TCP=
> algorithm on the sending side from attempting to find the size of the<= br> > queues in the network. =A0Search the list archives for "Blackpool= " to
> see my take on this technique in the form of a kernel patch. =A0More > sophisticated algorithms are doubtless possible.
>
You can tweak max receiver window to be really small.

# cat /proc/sys/net/ipv4/tcp_rmem
4096 =A0 =A087380 =A0 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=3Deth0
IFB=3Difb0
LOCALNETS=3D"hard.coded.ip.addresseses/netmasks"
# Put a limit a bit under real one, to 'own' the queue
RATE=3D"rate 7Mbit bandwidth 7Mbit maxburst 80 minburst 40"
ALLOT=3D"allot 8000" # Depending on how old is your kernel...

=A0
=
A subtlety here is that several technologies in use today
(wireless-n, = cable, green ethernet, GRO) are highly 'bursty',
and I'd reg= ard minburst, maxburst as something that needs to be calculated as a respec= table fraction of the underlying rate.

=A0
modprobe ifb
ip link set dev $IFB up

tc qdisc add dev $ETH ingress 2>/dev/null

tc filter add dev $ETH parent ffff: \
=A0 protocol ip u32 match u32 0 0 flowid 1:1 action mirred egress \
=A0 redirect dev $IFB

tc qdisc del dev $IFB root


# Lets say our NIC is 100Mbit
tc qdisc add dev $IFB root handle 1: cbq avpkt 1000 \
=A0 =A0rate 100Mbit bandwidth 100Mbit

tc class add dev $IFB parent 1: classid 1:1 cbq allot 10000 \
=A0 =A0 =A0 =A0mpu 64 rate 100Mbit prio 1 \
=A0 =A0 =A0 =A0bandwidth 100Mbit maxburst 150 avpkt 1500 bounded

# Class for traffic coming from Internet : limited to X Mbits
tc class add dev $IFB parent 1:1 classid 1:11 \
=A0 =A0 =A0 =A0cbq $ALLOT mpu 64 =A0 =A0 =A0\
=A0 =A0 =A0 =A0$RATE prio 2 \
=A0 =A0 =A0 =A0avpkt 1400 bounded

tc qdisc add dev $IFB parent 1:11 handle 11: sfq


# Traffic from machines in our LAN : no limit
for privnet in $LOCALNETS
do
=A0 =A0 =A0 =A0tc filter add dev $IFB parent 1: protocol ip prio 2 u32 \ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0match ip src $privnet flowid 1:1
done

tc filter add dev $IFB parent 1: protocol ip prio 2 u32 \
=A0 =A0 =A0 =A0match ip protocol 0 0x00 flowid 1:11



_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
= https://lists.bufferbloat.net/listinfo/bloat



--
Dave T=E4ht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net



--
Dave T=E4ht=
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat= .net
--0016e6d62550fc975e04b8384cd4--