[Commotion-dev] QOS, Commotion, and Tomato's

[Will Hawkins]

As a follow-up to this, I just had a workshop participant come to me and 
reiterate the importance of gateway control. In his network, he says 
that it would be useful to:

a) configure whether a gateway is used at all (on/off)
b) configure a specific subset of IP addresses for gateway access

in addition to being able to limit the amount of bandwidth offered to 
the mesh users from a gateway. Ryan, Andy and I talked about how this 
could be accomplished and I realize that it's already technically 
possible and may already even be doable from the web UI. I just wanted 
to flag it specifically so that we can keep it on the top of our mind.

The other consistent theme we've heard from participants this week is 
that they really want to be able to control (anticipate) how 
olsrd/smartgw handle multiple gateways on the same mesh.

Ryan, Andy: Anything to add specifically related to gateway/QoS control 
from what we've heard this week?

Will



On 06/07/2013 03:02 PM, Will Hawkins wrote:
> On 06/07/2013 02:58 PM, Ben West wrote:
>>
>> On Fri, Jun 7, 2013 at 1:34 PM, Will Hawkins
>> <hawkinsw at opentechinstitute.org <mailto:hawkinsw at opentechinstitute.org>>
>> wrote:
>>
>>     On 06/07/2013 01:11 PM, Ben West wrote:
>>
>>         Is the thinking here along the lines of building UI elements on
>>         top of
>>         the QOS implementation already provided via qos-scripts and
>>         luci-apps-qos?  Or an entirely new OOS implementation?
>>
>>         If you're looking at an entirely new OOS implementation, a
>> possible
>>         difficulty is that OpenWRT AA has adopted bleeding edge kernel
>>         versions
>>         obsolete certain methods typical to older QOS
>> implementations.  Most
>>         recently in a thread on this list, the departure of IMQ from the
>>         kernel
>>         layer rendered the bandwidth throttling features of the
>> nodogsplash
>>         captive portal inoperative.
>>
>>
>>     Would you mind sending a link to any information you have about IMQ
>>     inclusion/removal from the kernel? I'm just curious is all!
>>
>>
>> Here is what I've found about it.  IMQ no longer exists in Attitude
>> Adjustment or trunk, to my understanding.
>>
>> http://wiki.openwrt.org/doc/uci/qos
>> https://forum.openwrt.org/viewtopic.php?id=28947
>> http://wiki.openwrt.org/doc/howto/packet.scheduler/packet.scheduler?s[]=imq#required.packages
>>
>>
>> The actual changeset removing imq:
>> https://dev.openwrt.org/changeset/25641/trunk
>>
>> Preferred replacement implementations should use IFB:
>> http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb
>>
>>     Will
>
> Looks like we found the same information :-)
>
> Will
>
>>
>>
>>         Do you know what kernel version EasyTomato is bundling?  I
>> believe
>>         Tomato itself is still wedded to kernel v2.6 (or older?) and
>>         unfortunately fully obsolete for the topic at hand.
>>
>>         Besides all that, it may just be simplest to encourage the end
>>         user to
>>         input their overall Up/Down bandwidth values into any QOS admin
>>         UI form,
>>         rather than having the node itself try to determine that.  It
>>         could be a
>>         basic step like "connect your laptop directly to your Internet
>>         connection and run speedtest.net <http://speedtest.net>
>>         <http://speedtest.net> a few times ..."
>>
>>
>>         On Fri, Jun 7, 2013 at 8:08 AM, Seamus Tuohy
>>         <s2e at opentechinstitute.org <mailto:s2e at opentechinstitute.org>
>>         <mailto:s2e at opentechinstitute.__org
>>         <mailto:s2e at opentechinstitute.org>>> wrote:
>>
>>              Hello All,
>>
>>              I dropped development on a user interfacefor the QOS work a
>>         few weeks
>>              ago and I wanted to give an update in case anyone wants to
>>         take it on in
>>              the future.
>>
>>              Looking at various interfaces I think that modifying the
>> Tomato
>>              interface for QOS
>>         http://www.easytomato.org/__features/scheduled-rules/
>>         <http://www.easytomato.org/features/scheduled-rules/>,
>>              which is based on the Toastman version of Tomato
>>
>> http://linksysinfo.org/index.__php?threads/toastman-releases.__36106/
>>
>> <http://linksysinfo.org/index.php?threads/toastman-releases.36106/>,
>>         is
>>              the best option for implementing QOS on Commotion. It is
>>         currently built
>>              for DD-Wrt, but looking at the scripts it mainly creates TC
>>         files, and
>>              as such, would be an easy enough lift to move over to
>>         OpenWRT and LuCI.
>>              Though, there will be some extra work fiddling with
>>         multiple zone rules.
>>
>>              Below is some useful info from William Dixon at Easy Tomato
>>         that I
>>              thought would be useful to append to this if anyone wants
>>         to continue
>>              this work.
>>
>>              "One of the really hard parts of this is to automatically
>>         figure out
>>              your connection speed without constantly blasting huge
>>         amounts of data
>>              over the network (you need your speed for QoS settings and
>>         they can
>>              fluctuate a lot during a day).  There are a few ways to do
>>         it, but its a
>>              lot of work, but really needs to a grad research project.
>>           We were
>>              hoping research group at GaTech would do it for us, but
>>         that's looking
>>              less likely.
>>
>>              This is
>>
>>
>> long<http://www.linksysinfo.__org/index.php?threads/using-__qos-tutorial-and-discussion.__28349/
>>
>>
>> <http://www.linksysinfo.org/index.php?threads/using-qos-tutorial-and-discussion.28349/>>,
>>
>>              but a very good overview of how QOS stuff works.  It takes
>>         a LOT of
>>              fiddling to get it really sail (and more dangerously, some
>>              counterintuitive settings), but once it does, it's awesome!
>>           We got a
>>              hospital with 100 computers to go from website timeouts to
>>         skype calls
>>              with a single router!"
>>
>>
>>              s2e
>>              _________________________________________________
>>              Commotion-dev mailing list
>>         Commotion-dev at lists.chambana.__net
>>         <mailto:Commotion-dev at lists.chambana.net>
>>              <mailto:Commotion-dev at lists.__chambana.net
>>         <mailto:Commotion-dev at lists.chambana.net>>
>>
>>         https://lists.chambana.net/__mailman/listinfo/commotion-dev
>>         <https://lists.chambana.net/mailman/listinfo/commotion-dev>
>>
>>
>>
>>
>>         --
>>         Ben West
>>         http://gowasabi.net
>>         ben at gowasabi.net <mailto:ben at gowasabi.net>
>>         <mailto:ben at gowasabi.net <mailto:ben at gowasabi.net>>
>>         314-246-9434 <tel:314-246-9434>
>>
>>
>>
>>         _________________________________________________
>>         Commotion-dev mailing list
>>         Commotion-dev at lists.chambana.__net
>>         <mailto:Commotion-dev at lists.chambana.net>
>>         https://lists.chambana.net/__mailman/listinfo/commotion-dev
>>         <https://lists.chambana.net/mailman/listinfo/commotion-dev>
>>
>>
>>     _________________________________________________
>>     Commotion-dev mailing list
>>     Commotion-dev at lists.chambana.__net
>>     <mailto:Commotion-dev at lists.chambana.net>
>>     https://lists.chambana.net/__mailman/listinfo/commotion-dev
>>     <https://lists.chambana.net/mailman/listinfo/commotion-dev>
>>
>>
>>
>>
>> --
>> Ben West
>> http://gowasabi.net
>> ben at gowasabi.net <mailto:ben at gowasabi.net>
>> 314-246-9434
>
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> https://lists.chambana.net/mailman/listinfo/commotion-dev
>