From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 741123B29E; Thu, 16 Feb 2017 11:15:29 -0500 (EST) Received: by mail-wm0-x235.google.com with SMTP id r141so19051352wmg.1; Thu, 16 Feb 2017 08:15:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HLs8k1ck8KyukDtGYRwz53iv7vzzdLEIaXu7Bx2z26U=; b=nXMURFFbyjwyN5OkFKbdHgT0G2pbi6J4bBgLJcMpYOi+CW+1N13IQaCCDwP61EkJhI y4a+D/gIl7Hd6H/fs2Weca+O7WzA667MXbtenZv527AYF6XOzMO3T3pdRsxEPmnblAou tWPBZ80eUU1/dGvCAV3IUuJ3BqyrOvhnucjCVkGg4TQDQ/CwKBg2C8Hp+6oMbY3NWk1C uNFOgvP1yqOqz5qQak20nbUx8SsJ+9j4vw3e3r8s6eJzobmFhXDBRSbJsI/H+x/mXqyN bqGx33s7kuKxK76f0ZRE32f8a6zoHCejwUC+BJNOjZ/VrltLcYU+zOYAkOW9Nd+D4/67 uQVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HLs8k1ck8KyukDtGYRwz53iv7vzzdLEIaXu7Bx2z26U=; b=MDQK7bulUE80WNyRDWIbs0ro9ylybPV+n+u/cm56dAMgeUO53C6pV+WmckUNoJXjsp 58v4chRtZoz3ko0j9ipK9LUK3+kNY2PYdyv37JFdcaBudjRomMJoc1KCEy7jeSmZHq2e aeLdFHhTRsBm35fQ0sgpO3+vlUuB/+zIinKGu2TahvYREXeV2FNTs2KhcT6vhhedc85O nGlr2VvbQ8koYtXG3vAhJCL4YWkjQo/9b5qB5rLQu66DxBaSDWGOpNcGKDNxAUNMP3hZ Zq6nQ1ODNHjoVDf3sh1XnPuUllZ/NAbdEXoduuOiVAkTKd7we9Jp4ldHe3xiHzUTWtrt YB4g== X-Gm-Message-State: AMke39mKvoLJf493CTNADC5boRrmVm1IiggMsm98IlbxtqCvGtQgcVPMOWlyJxrwF3YgXdTkDaLLhj0lPG+Uig== X-Received: by 10.28.191.208 with SMTP id o77mr3096378wmi.117.1487261728421; Thu, 16 Feb 2017 08:15:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.8.194 with HTTP; Thu, 16 Feb 2017 08:15:27 -0800 (PST) In-Reply-To: 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> From: Aaron Wood Date: Thu, 16 Feb 2017 08:15:27 -0800 Message-ID: To: Pete Heist Cc: Sebastian Moeller , cake@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=94eb2c06451202c03a0548a81b2d 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:15:29 -0000 --94eb2c06451202c03a0548a81b2d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. But I can certainly see the case being made that the VO and VI queues are never allowed to be over X% of traffic. -Aaron On Thu, Feb 16, 2017 at 1:17 AM, Pete Heist wrote: > > > On Feb 16, 2017, at 9:42 AM, Sebastian Moeller wrote: > > > >> On Feb 16, 2017, at 08:57, Pete Heist wrote: > >> [=E2=80=A6 discussion about DSCP to WMM classes mapping] > >> This always makes me wonder what=E2=80=99s to keep someone from just m= arking > all their traffic 0x7 and stomping over everyone else. > > > > I have a gut feeling that an AP in a untrusted/hostile environmen= t > should monitor the usage of the 4 different WMM classes and step up their > class accordingly. That is in an environment where there is a lot of AC_V= O > or AC_VI traffic the AP should elevate its normal data packets priority t= o > match as not too be drowned out by the other senders. Sort of a reciproca= l > tit-for-tat approach, with the goal that the AP will keep access to a > decent share of airtime. But since I am a layman in these matters, I migh= t > be out to lunch on this=E2=80=A6 > > At first I was thinking to just remove diffserv markings entirely, say > with Cake=E2=80=99s besteffort flag, but I think that =E2=80=9Cgood=E2=80= =9D and =E2=80=9Cotherwise > unknowing=E2=80=9D users would suffer, which I think in FreeNet is a vast= majority > of users. > > I think the challenge might be what metric to use to know when classes ar= e > being abused. Maybe roughly if dscp_value * bytes_transferred exceeds som= e > threshold in some given period of time, that would work. Best effort > wouldn=E2=80=99t affect this metric so they can use this class all they w= ant, and > if someone just uses their connection for typical VoIP usage, the thresho= ld > shouldn=E2=80=99t be exceeded. Only when a lot of data is transferred per= period of > time in higher classes would they exceed the threshold. > > For now, we could just measure this (with iptables?) and send an admin > email when the threshold is exceeded, then automate a strategy to combat = it > if needed. But I bet most users in a community WISP, if notified, would > just try to help fix the problem=E2=80=A6 :) > > Pete > > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast > --94eb2c06451202c03a0548a81b2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The approach that's in all of the Cisco documentation = (FWIW) about such things for wired networks is that the higher-priority tra= ffic classes for VoIP and video are also bandwidth limited to a fraction of= the total (and less than a majority, at that).=C2=A0 But that's in an = environment where you _can_guarantee a minimum level of service.=C2=A0 With= the changing throughput rates of wifi, that's a bit harder.

But I can certainly see the case being made that the VO and VI que= ues are never allowed to be over X% of traffic.

-A= aron

O= n Thu, Feb 16, 2017 at 1:17 AM, Pete Heist <peteheist@gmail.com><= /span> wrote:

> On Feb 16, 2017, at 9:42 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
>
>> On Feb 16, 2017, at 08:57, Pete Heist <peteheist@gmail.com> wrote:
>> [=E2=80=A6 discussion about DSCP to WMM classes mapping]
>> This always makes me wonder what=E2=80=99s to keep someone from ju= st marking all their traffic 0x7 and stomping over everyone else.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I have a gut feeling that an AP in a untrust= ed/hostile environment should monitor the usage of the 4 different WMM clas= ses and step up their class accordingly. That is in an environment where th= ere is a lot of AC_VO or AC_VI traffic the AP should elevate its normal dat= a packets priority to match as not too be drowned out by the other senders.= Sort of a reciprocal tit-for-tat approach, with the goal that the AP will = keep access to a decent share of airtime. But since I am a layman in these = matters, I might be out to lunch on this=E2=80=A6

At first I was thinking to just remove diffserv markings entirely, s= ay with Cake=E2=80=99s besteffort flag, but I think that =E2=80=9Cgood=E2= =80=9D and =E2=80=9Cotherwise unknowing=E2=80=9D users would suffer, which = I think in FreeNet is a vast majority of users.

I think the challenge might be what metric to use to know when classes are = being abused. Maybe roughly if dscp_value * bytes_transferred exceeds some = threshold in some given period of time, that would work. Best effort wouldn= =E2=80=99t affect this metric so they can use this class all they want, and= if someone just uses their connection for typical VoIP usage, the threshol= d shouldn=E2=80=99t be exceeded. Only when a lot of data is transferred per= period of time in higher classes would they exceed the threshold.

For now, we could just measure this (with iptables?) and send an admin emai= l when the threshold is exceeded, then automate a strategy to combat it if = needed. But I bet most users in a community WISP, if notified, would just t= ry to help fix the problem=E2=80=A6 :)

Pete

_______________________________________________
Make-wifi-fast mailing list
Make-wifi-fast@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/mak= e-wifi-fast

--94eb2c06451202c03a0548a81b2d--