Hi, A thought for the list. As I mentioned in another posting, there are a lot of QoS mechanisms out there. Linux supports some, but not all. Some patchsets add others, but don''t work for all kernels. There are also userland implementations, usually sitting in software routers, but there are other packages. Would it be helpful if I worked on a table of what''s out there for Linux and in what form? The main drawback of such a list is that while I can tell you if such-and-such an implementation exists, that doesn''t mean the implementation is any good, or that the QoS concept is valid. There are plenty of arguments amongst QoS researchers as to whether RED is useful or not, and those are the people most qualified to know the answer. Nor would I be able to verify what kernel patches work well together, so the individual existance of specific mechanisms doesn''t mean you can combine them usefully. On the other hand, there doesn''t seem to be any easy way for people to find out what does exist, what doesn''t exist YET for Linux but could easily be written, or what used to exist but has been dropped for reasons known or unknown. For example, SGI''s "Scheduled Transfer Protocol", MPLS, WRR and ESFQ are all examples of networking algorithms that are apparently deceased. The Layer 7 packet classifier isn''t dead, but doesn''t apply cleanly to kernels 2.6.9 or later. Finding these can be fun, too. I''ve got a copy of the Scheduled Transfer Protocol patches, but that''s because I downloaded them while they were still on SGI''s FTP site. If they exist anywhere on the Internet today, I haven''t the foggiest where. The site for ESFQ is dead, and the only known patches forward-ported to recent kernels is merged into the qnet patch series, making it hard to extract. Any thoughts on this? Jonathan __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Tuesday 04 January 2005 23:24, Jonathan Day wrote:> Hi, > > A thought for the list. As I mentioned in another > posting, there are a lot of QoS mechanisms out there. > Linux supports some, but not all. Some patchsets add > others, but don''t work for all kernels. There are also > userland implementations, usually sitting in software > routers, but there are other packages. > > Would it be helpful if I worked on a table of what''s > out there for Linux and in what form?Possibly. I only know of CBQ, HTB, HFSC, SFQ, TBF, PFIFO, PRIO, G/RED for Linux offhand.> The main drawback of such a list is that while I can > tell you if such-and-such an implementation exists, > that doesn''t mean the implementation is any good, or > that the QoS concept is valid. There are plenty of > arguments amongst QoS researchers as to whether RED is > useful or not, and those are the people most qualified > to know the answer. Nor would I be able to verify what > kernel patches work well together, so the individual > existance of specific mechanisms doesn''t mean you can > combine them usefully.Yeah, QoS isn''t exactly a plug and play experience.> On the other hand, there doesn''t seem to be any easy > way for people to find out what does exist, what > doesn''t exist YET for Linux but could easily be > written, or what used to exist but has been dropped > for reasons known or unknown.I wrote a guide, Practical Guide to Linux Traffic Control[1], which I keep up to date as developments change. I only cover stuff in the mainline kernel for the most part, though. [1] http://trekweb.com/~jasonb/articles/traffic_shaping/> For example, SGI''s "Scheduled Transfer Protocol", > MPLS, WRR and ESFQ are all examples of networking > algorithms that are apparently deceased. The Layer 7 > packet classifier isn''t dead, but doesn''t apply > cleanly to kernels 2.6.9 or later.Layer 7 does patch against 2.6.9 with an experimental patch available since the beginning of December on the project''s SF page. It Works For Me (tm) but I guess it hasn''t been tested sufficiently such that it''s now available as a stable 2.6.9+ patch.> Finding these can be fun, too. I''ve got a copy of the > Scheduled Transfer Protocol patches, but that''s > because I downloaded them while they were still on > SGI''s FTP site. If they exist anywhere on the Internet > today, I haven''t the foggiest where. The site for ESFQ > is dead, and the only known patches forward-ported to > recent kernels is merged into the qnet patch series, > making it hard to extract.That''s too bad. I had wanted to include something about ESFQ but never got around to it, since SFQ generally suits my needs. -- Jason Boxman Perl Programmer / *NIX Systems Administrator Shimberg Center for Affordable Housing | University of Florida http://edseek.com/ - Linux and FOSS stuff _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
The URL for the guide was useful, thanks. Here are a few other QoS systems for Linux: RSVP is provided in the stock kernel. This allows you to reserve a given amount of bandwidth for a specific UDP data stream. It is typically not used in "the real world" because it doesn''t scale well. Too much state information needs to be transmitted and kept track of, to be useful on backbone routers. USAGI is based on KAME, and KAME supports ALTQ. In turn, ALTQ supports HFSC, JoBS, RIO and BLUE for both IPv4 and IPv6. It is NOT clear from the USAGI web page as to whether ALTQ is included in their code. http://www.linux-ipv6.org/ http://www.csl.sony.co.jp/person/kjc/kjc/software.html QLinux supports H-SFQ, but is based on Linux 2.2 and the 2.4 sources don''t seem to have ever been released. http://lass.cs.umass.edu/software/qlinux/ DGT2684 (seems to be dead, unless the pseudo-QoS for ATM in the Linux kernel is based on this, but then the code on Sourceforge should be current, you''d have thought) http://sourceforge.net/projects/dgt2684 I''m not altogether sure what SIMA did, but it seems to have been a queueing system of sorts for the 2.2 kernels. http://www.atm.tut.fi/faster/sima/ It''s a cheat, but you can route traffic onto and off Network Simulator and therefore use any QoS devices available for that for regular networking. This includes Fair Queueing, Stochastic Fair Queueing and Deficit Round Robin, by default. Many of the ALTQ routines have NS implementations, as well, and I''m sure there are others. NS seems to be popular with protocol researchers. http://www.isi.edu/nsnam/ns/ There''s also a QoS Library which provides a useful API for applications. http://www.coverfire.com/lql/ Finally, I also mentioned SGI''s STP patch. STP allows you to reserve network resources for a future data stream. As far as I can tell, it is very similar in concept to RSVP, except that it is not UDP-specific and is specifically designed for very high-speed networks, where constructing and destructing connections at the time of use can add excessive latency. By pre-allocating, the connection can all be set up and ready to use when it is actually needed. --- Jason Boxman <jasonb@edseek.com> wrote: (snip)> Possibly. > > I only know of CBQ, HTB, HFSC, SFQ, TBF, PFIFO, > PRIO, G/RED for Linux offhand.(snip) __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/