On Sun, 20 Dec 2009 13:31:00 -0500 "Brian J. Murrell" <[email protected]> wrote:
> On Sun, 2009-12-20 at 16:47 +0000, [email protected] wrote: > > I am trying limit the amount of bandwidth users consume for services > > other than VOIP. > > Which seems to be 90% of the requests for TC/QOS to this list. > > Tom: I wonder if the TC/QOS stuff can be abstracted (read: dumbed > down) into more simple configuration for the usual cases, like VOIP > (for one). I think an excellent first step would be for someone who successfully uses Shorewall traffic shaping with VOIP to write a HOWTO. I don't have VOIP and I refuse to install it just so I can write such a HOWTO. > > For example, it seems that given this very frequent case, VIOP, I > would think that one wants to always give highest priority to VIOP > (to the limit of 100% of the bandwidth I would think[1]) and let > everything else fight it out the remaining bandwidth (i.e. like most > people without VOIP needs do for 100% of their bandwidth). IOW, for > VOIP situations, it seems more appropriate to simply prioritize > traffic rather than creating minimum/maximum/lending/borrowing bands > for it. This requires someone who has the problem (has VOIP and wants to handle it with Shorewall Traffic Shaping) and has the talent to implement a better solution *and has the time to support the code once it is released*. > > Given that policy routing also utilizes the TC configuration files, it > would be nice to see a simpler, more rule based policy routing > configuration as well. One that mimics a regular routing file but > allows port specification, etc. Policy routing *may* use firewall marks. For historical reasons, firewall marks in Shorewall are assigned in the tcrules file. One thing that I plan to do in Shorewall 4.6 is to take advantage of the fact that later kernels allow packet marks to be assigned in the filter table. This will allow for the eventual obsolescence of the tcrules file in favor of the rules file. > > Given that I don't do routing/qos for a living (i.e. keeping my > knowledge cache of TC in Linux fresh) and only ever visit > periodically, the tc{classes,rules} file gives me a headache every > time I do have to go back to it and realize I have forgotten what I > had to re-learn the last time I wanted to fiddle with it. I don't do anything even related to networking for a living. And I have the same problem with QOS (I have to go back to first principles each time I want to change it). > > In any case, it just seems to me that probably 90% of the QOS and > policy routing use-cases out there could be satisfied with a much > simpler configuration syntax -- one that insulates the user from the > terseness of Linux TC. > > Perhaps it's a case of yes, this is all a good idea -- somebody just > needs to find the time to implement it. :-) And document it. And support it. Those take much more effort than writing the code... -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
