From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (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 628873B29E; Thu, 16 Feb 2017 11:51:11 -0500 (EST) Received: by mail-wr0-x241.google.com with SMTP id z61so1959133wrc.3; Thu, 16 Feb 2017 08:51:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VafsmU7KVSjkzf74qLqkTgl7Xh1Q9t+ZmXlH1I/9xJU=; b=l0J2+LBdYgxXbs6H/f3W+RlLda9BrUUg51/lw5GvzLBUxv7vqXO7pNlGd/c9s8YdPT MVOue5aWzz6forKrRT5eioB9ViUhgcu3NTHL6ix/7a8X4/X0dtfrtKPu37SaVT/Ull71 EFr/gZPhExhCnapJ9C5r73Dao12NFEVL+7fH4y2iPpEUO0BikinLDPsNC8tz8xEOECap 2i+WfDx7+AXC3uZwfMlMKYERWBS5iq+XsLsywawGUhXodhF0AfkjveQ4EYe6zKl/okrn MtPXii2bolpt/ZHmkuLgCaad1EsHZ8AVrpHkFF+gOKH1EzhuxyTcaEmW7QHYl+owwoQK xHGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VafsmU7KVSjkzf74qLqkTgl7Xh1Q9t+ZmXlH1I/9xJU=; b=lREpOMoMTBFTFIWbMyrd8r+eEbvIt/izrfvUZjSYxbYCVxN0PMfAQCCKnQ+ubI4tEX PgnePIucLIHVZI0od1tbPnEAiMjB3hQA0TMgfAIQzAhMNB73OUz1S8NUO9xqEsh4imI5 +/49vCKbtgrG/+wud1cv5DWkDhMg8tMpYSyS/kdKWg7wSWuZ0Mzn8ymSBSf1HC4imyRZ pqaK82nM7VyC/TZgEzDW+ECG2hH7/EyE3MVwIilkMmKqG4CX1n4HqDYPYvu4dsDHpNGy KYAD8Fz1rF2PWqlFwkcohr217wdoXvQ0Ao9VskMMglv4kBBYMfGYMfq/0cFQa3B25PSi 6lbg== X-Gm-Message-State: AMke39msmulcD5Xh+g/Yqn7H/aFj/wZMTaAzXEEewqLJzw+aUqG1ISd+IhalFgwgYc44GQ== X-Received: by 10.223.150.238 with SMTP id u101mr2991574wrb.175.1487263870369; Thu, 16 Feb 2017 08:51:10 -0800 (PST) Received: from [10.72.0.34] (h-1169.lbcfree.net. [185.99.119.68]) by smtp.gmail.com with ESMTPSA id 10sm9636342wrw.13.2017.02.16.08.51.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 16 Feb 2017 08:51:09 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Pete Heist In-Reply-To: Date: Thu, 16 Feb 2017 17:51:30 +0100 Cc: cake@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <32C42951-373F-4D90-8936-AA07039E5D73@gmail.com> <877f5c2pew.fsf@toke.dk> <42AC44CD-8C22-4EBC-B6AB-7786BA505D07@gmail.com> <35E83BE1-73D8-4FF9-B2E8-A49073E67EBA@gmail.com> To: Sebastian Moeller , Aaron Wood X-Mailer: Apple Mail (2.3124) Subject: Re: [Make-wifi-fast] [Cake] Flent results for point-to-point Wi-Fi on LEDE/OM2P-HS available X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:51:11 -0000 > On Feb 16, 2017, at 5:21 PM, Sebastian Moeller = wrote: >=20 >=20 >> On Feb 16, 2017, at 17:15, Aaron Wood wrote: >>=20 >> The approach that's in all of the Cisco documentation (FWIW) about = such things for wired networks is that the higher-priority traffic = classes for VoIP and video are also bandwidth limited to a fraction of = the total (and less than a majority, at that). But that's in an = environment where you _can_guarantee a minimum level of service. With = the changing throughput rates of wifi, that's a bit harder. >>=20 >> But I can certainly see the case being made that the VO and VI queues = are never allowed to be over X% of traffic. >=20 > I guess the problem is that any station can just decide by = itself to just send AC_VO and in a typical home steup the AP will not = get a say in that. This is why I propose the AP to escalate its own = priority marking to get its packets distributed=E2=80=A6 In a sense if = there are thresholds for permissible VO/VI traffic fractions below which = the AP will not escalate its own priority this will come close to = throttling the high priority senders, no?=20 I thought Aaron=E2=80=99s suggestion sounds both sensible and not = difficult to implement. That way we wouldn=E2=80=99t even have to = regularly monitor it, and anyone who is marking all their packets = thinking they=E2=80=99re doing themselves a favor is just limiting their = max throughput. Could there be another keyword in Cake to do this automatically, say = =E2=80=9Cfairdiffserv", or would this just be feature bloat for what is = already a sophisticated shaper? I don=E2=80=99t know if there are = sensible mappings from dscp value to max percentage throughput that = would work most of the time, or if there could also be an adjustable = curve parameter that controls the percentage backoff as you go up dscp = levels. Sebastian, I wasn=E2=80=99t sure what you meant by the AP=E2=80=99s = =E2=80=9Cown packets=E2=80=9D, ones that originate from the AP? One = thing with might happen if you raise some priorities is there may be an = arms race, and also once packets are forwarded to an upstream router = with an already elevated priority they might unfairly compete there, but = maybe you meant only to treat some packets differently in the AP, not to = actually change the value in the DSCP field... Pete