From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 863843CB35 for ; Sun, 3 Mar 2019 11:29:01 -0500 (EST) Received: by mail-io1-xd34.google.com with SMTP id x3so2119572ior.6 for ; Sun, 03 Mar 2019 08:29:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=sPvSOsYBJYFNIIEHzoicsYRC6dUiI8tLDEIB9sSDz3o=; b=MMAVjDj/v9AoGnWAVTNWxm9t0FpBw/5XJFaQyRCNHJIhH8OVeiG970FR5mZgd36cq/ D8+wGt2yJFTZKyI3MhOQNzuIQHIzR7yB9aMKz0Qdt6+EcRbJggDOWCs3LkRxjo3jzfdN 9sUWTC52DNIgBBBf1LJJNSzbYQHSiByh1VXZxb741m2bC+8BuNTFv6nuKrQx04BW89Jc 73xjRj5sJUcuDRXcuM2RpXHucQbbBbnik1NXsg4MXb/xnLABpkELOA97zq8slfAeTGnG Kb5xKZs8NO8sy9HA0h2TaO1k5Fiz2NBxAo03A8Lza2jOuYLou+HwnhLyDQqaIQKH3TVl 3KaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sPvSOsYBJYFNIIEHzoicsYRC6dUiI8tLDEIB9sSDz3o=; b=pt4kSwSFCMundOJaXMBJ6d8Amqfxq+6tpV2Sf2mfRSLfAyJe1rr5wu2gKUitN0A7uu 3vgyBXEhtsOaE0GFf99dLcHVRM02TWYx8C8odreuj1XEs4abcDlnGUXTOZkIQSJupZ18 81q5WTeYqFuwNrRPYDDQI/8ebvjrKHxbIWVnK166OqVDoWccmLC/2IMPPRRFAKZkuq4z bTFUEc2vZMnpiEK9VDm0GJ3hIrHETP44+nL746Ot89qi6baROA/HfwN0yx9K71p/ngsI MpN+K5zYlbcFrsO3/wpYHSt9HP4oLxGMVJYJrf9w/lrL4bwqKOJDEl4xy+QKX41nv8DL Uz9Q== X-Gm-Message-State: APjAAAWq51aXeOHbaf6BbzW3oB0ImBrXCKbwJly8api9BFAQLtxN8gD0 db44N1ifkJe2/GRMKPKIZVsmuQoO9q3EW4l4E1Ik+buc X-Google-Smtp-Source: APXvYqw1Wn/Ra2O13dWJDIAuXOyiJhCM8Zll5c/XKa6raL5uOVr7sxNjEJqbKignxoN5WcO4Jg4kwHM0HDfYqnf/ejI= X-Received: by 2002:a5e:8f4b:: with SMTP id x11mr7978371iop.217.1551630540726; Sun, 03 Mar 2019 08:29:00 -0800 (PST) MIME-Version: 1.0 From: Adrian Popescu Date: Sun, 3 Mar 2019 18:28:22 +0200 Message-ID: To: Cake List Content-Type: multipart/alternative; boundary="00000000000033e477058333237d" Subject: [Cake] Cake ingress experiments & policing X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2019 16:29:01 -0000 --00000000000033e477058333237d Content-Type: text/plain; charset="UTF-8" Hello, These are some some random thoughts and notes related to some of my experiments with cake and traffic shaping. The performance issues observed on the cake setup seemed to be worth another look. The mirred and ifb setup seemed to have lower performance than expected. This was easy enough to test by replacing cake with sfq on the ifb interface. The setup had the same performance issues as the setup with cake. It's most likely not reasonable to expect cake to be able to shape at 1 gbps either if a setup with something with less complexity can't deal with 300-400 mbps worth of MTU sized packets in the mirred and ifb setup. This set of experiments has determined me to consider alternative options for ingress. A policer seems to be the right choice. A policer which sets the ECN bit on ECT enabled flows could help. There doesn't seem to be a documented way of doing this with tc actions & filters. Would this be possible for IPv6 traffic? The ECN marking on ECT enabled flows is the missing bit which would make this work for IPv4. A pedit action may be useful if combined with a match on ECT. It's something I haven't figured out yet. Perhaps some tests with a simple flow blind marking policer would be worth a shot. Maybe it'd be worth to see other people's setups and even ISP type setups to figure out what else to try. Some of my other experiments included wifi ingress shaping. The upload speed seemed capped at 3-8 mbps while wifi was shaped on ingress. This appears to be a bug. Shaping wifi at a rate which is lower than that of the link's total bandwidth seems to be more difficult since we can't limit on ingress based on the egress interface. --00000000000033e477058333237d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

These are some some random = thoughts and notes related to some of my
experiments with cake and traff= ic shaping.

The performance issues observed on the cake setup seemed= to be worth
another look. The mirred and ifb setup seemed to have lower= performance
than expected.

This was easy enough to test by repla= cing cake with sfq on the ifb
interface. The setup had the same performa= nce issues as the setup with
cake.

It's most likely not reaso= nable to expect cake to be able to shape at
1 gbps either if a setup wit= h something with less complexity can't deal
with 300-400 mbps worth = of MTU sized packets in the mirred and ifb
setup.

This set of exp= eriments has determined me to consider alternative
options for ingress. = A policer seems to be the right choice.

A policer which sets the ECN= bit on ECT enabled flows could help. There
doesn't seem to be a doc= umented way of doing this with tc actions &
filters. Would this be p= ossible for IPv6 traffic? The ECN marking on
ECT enabled flows is the mi= ssing bit which would make this work for
IPv4. A pedit action may be use= ful if combined with a match on ECT.
It's something I haven't fi= gured out yet.

Perhaps some tests with a simple flow blind marking p= olicer would be
worth a shot.

Maybe it'd be worth to see othe= r people's setups and even ISP type
setups to figure out what else t= o try.


Some of my other experiments included wifi ingress shapin= g. The upload
speed seemed capped at 3-8 mbps while wifi was shaped on i= ngress. This
appears to be a bug.
Shaping wifi at a rate which is low= er than that of the link's total
bandwidth seems to be more difficul= t since we can't limit on ingress
based on the egress interface.
--00000000000033e477058333237d--