[LARTC] HFSC and that ATM overhead problem (Another VOIP QoS post. Ahhhh)
G'Day I would like to be able to use my VOIP telephone over a saturated ADSL link whilst enjoying optimum audio quality and utilising all of the bandwidth I pay for. It is about this situation that I write. HFSC appears to be the queueing discipline of choice for VOIP. In order for this to work, though, do I have to account for the ATM overhead in the small VOIP packets by defining my maximum root class bit rate as (measured max bit rate)*%50 (or some other awful percentage)? If the answer is yes to the above, does that mean that the next best solution would be HTB coupled with the newly updated http://www.adsl-optimizer.dk/? Would Shorewall with patched kernel and patched iproute2 be the most Luddite way of using adsl-optimizer? Ah, so many questions, sorry. Have a nice day. Regards Fog_Watch. -- Lose wait. Get Gentoo. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HFSC and that ATM overhead problem (Another VOIP QoS post. Ahhhh)
On Sunday 04 November 2007 12:04, Fog_Watch wrote: G'Day I would like to be able to use my VOIP telephone over a saturated ADSL link whilst enjoying optimum audio quality and utilising all of the bandwidth I pay for. It is about this situation that I write. HFSC appears to be the queueing discipline of choice for VOIP. In order for this to work, though, do I have to account for the ATM overhead in the small VOIP packets by defining my maximum root class bit rate as (measured max bit rate)*%50 (or some other awful percentage)? If the answer is yes to the above, does that mean that the next best solution would be HTB coupled with the newly updated http://www.adsl-optimizer.dk/? Ah! Thanks for pointing to us that the kernel devs finnally accepted the patches. Does someone know if the patched TC will work for kernel versions = 2.6.24? Would Shorewall with patched kernel and patched iproute2 be the most Luddite way of using adsl-optimizer? I don't use Shorewall, but rather an iptables script which works for most scenarios: http://downloads.angulosolido.pt/iptables/ If you don't use a patched kernel and if your system has only two network interfaces, you can use a script like this one: http://downloads.angulosolido.pt/QoS/HTB_shaper_basic.sh and take the overhead into account empirically (this one is HTB based). That is, start with the value the modem is synchronized for, fill the line with the average traffic you expect and lower the values until is OK. As you lower the upstream value you will find increasingly better latency values (try with ping + voip app). The best way is indeed patching the kernel and tc so that the overhead is automatically taken into account. I haven't done it yet, since that process doesn't scale for using across multiple systems of different versions. Now that the kernel patches were accepted things may change :-) Best regards Gustavo -- Angulo Sólido - Tecnologias de Informação http://angulosolido.pt ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HFSC and that ATM overhead problem (Another VOIP QoS post. Ahhhh)
On dom, 2007-11-04 at 23:04 +1100, Fog_Watch wrote: HFSC appears to be the queueing discipline of choice for VOIP. Is it? Any pointers? -- Giovanni Bajo ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Bridging two subnets selectively using routing
On 11/2/2007 11:35 PM, Corey Hickey wrote: I meant to do both, which I think is necessary in order to make the OPs proposed scheme work without modification. I'll defer if I'm wrong, though--I haven't tested it, and, as you said in your other email, it's a very weird scenario. As long as there are routes in both directions there should be no need for SNATing. I don't think this will work unless BR has a route like: # ip route add 192.168.4.0/24 via 10.3.0.13 dev eth0 ...whereas the OP only specified wanting routes to a few specific machines rather than the whole networks. In any case, debating that is probably academic, since I agree with you in principle. It should be cleaner to set up routes for the whole networks and use iptables rules on A1 to only allow traffic to/from specified hosts. Agreed. I mis read the routes on the two routers AR and BR to be for the entire networks. Though again presuming there are routes, things should work. This is more just a semantical mis-interpretation on the scope of what the routes are for. There are certainly different ways to do it, and I furthermore agree with you that using a separate link between AR and BR (as you suggested in your earlier message) is cleaner still. I prefer bridging in this situation mostly because it distributes traffic and reduces the load on the routers. I can see how this would reduce load on the routes, but I don't believe that load on routers will be much of a concern. (At least the routers that I use (pick any box (less than 10 years old) and install Linux) would do just fine. However I would be concerned about broadcast storms being propagated across the bridge unnecessarily. But if steps are taken to mitigate that then it is probably not that big of an issue. The two networks in question are rather small and occupy adjoining buildings. Network A had to be rebuilt after getting torn out while the corresponding building underwent a very intrusive retrofit and remodeling. Prior to that, the two networks were bridged and shared the same subnet. I don't know if the OP has a reason to isolate them from each other now. Ok... Obviously you are probably in a very unique position knowing the history of the network. I guess I'll go ahead and describe the former setup in a little detail. Every host in the entire bridged network was given an IP address within the subnet 10.0.0.0/8. The bridge was configured to drop all DHCP packets, so there was a DHCP server on network A and another on network B. Ok... Hosts on network A were given addresses in the following ranges[1]: 10.0.0.0/16 10.1.0.0/16 10.2.0.0/16 Hosts on network B were given addresses in the following range: 10.3.0.0/16 ...but, regardless of which network a host was on, it still was given the /8 subnet, so hosts could communicate over the bridge without any further configuration. Ok, you chose to do in bridging what most people do in routing. Seeing as how things were bridged you had to put things in place to stop things that would naturally leave the subnet. Your preference to have and work with. Since each network had its own router to the Internet, the DHCP servers also specified separate gateways. The bridge was configured to drop packets with sources or destinations that didn't match the IP ranges corresponding to the source/destination networks[2]. Ok... That's all. So let me get this right, you did bridging rather than routing to avoid load on the router(s)? Yet you had to put more load on the bridging host to segregate the networks like they would be if they were routed while still allowing host to host communications between the two buildings? personal opinion Strange /personal opinion My philosophy was to allow unrestricted communication over the bridge and gently LART users that caused trouble (always inadvertently; Windows worms and such). If the OP wants to allow communication only to a few hosts, that's no more difficult--just write a few rules to accept desired traffic and then drop/reject the rest. Ok. [1] Given the chance to do it over, I would have allocated addresses to network A from 10.0.0.0/18 and network B from 10.4.0.0/18 in order to simplify a little bit. Also, I should mention that the use of several /16 ranges doesn't mean we had anywhere near that many hosts; the separation was just for management. *nod* [2] Just in case some users on network B tried to manually set their IP address and gateway in order to use the better Internet access of network A. Of course, they could still have tunneled through the bridge to an accomplice on network A, but they could have also used an accomplice's wireless router, or CAT-5 strung between rooftops, or RFC 1149, etc. I dealt with such things on a case-by-case basis. :) That's what a Clue-by-4 is used for. ;) All in all you chose to implement a solution in one way that very like did exactly what you
Re: [LARTC] HFSC and that ATM overhead problem (Another VOIP QoS post. Ahhhh)
Giovanni Bajo wrote: On dom, 2007-11-04 at 23:04 +1100, Fog_Watch wrote: HFSC appears to be the queueing discipline of choice for VOIP. Is it? Any pointers? Well, it can decouple bandwidth and delay. And both are important here. Some documentation pointers: http://linux-ip.net/articles/hfsc.en/ http://www.cs.cmu.edu/~istoica/hfsc-tr.ps.gz (deep, but good read) http://www.sonycsl.co.jp/~kjc/software/TIPS.txt (regarding implementation in *BSD) http://marc.info/?t=10779959141r=1w=2 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HFSC and that ATM overhead problem (Another VOIP QoS post. Ahhhh)
On Sun, 04 Nov 2007 15:34:07 +0100 Giovanni Bajo [EMAIL PROTECTED] wrote: On dom, 2007-11-04 at 23:04 +1100, Fog_Watch wrote: HFSC appears to be the queueing discipline of choice for VOIP. Is it? Any pointers? I was going on gut instinct from vague information I read cruising around. Michal Soltys has given the hard references. -- Lose wait. Get Gentoo. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HFSC and that ATM overhead problem (Another VOIP QoS post. Ahhhh)
On Sun, 4 Nov 2007 12:46:37 + Gustavo Homem [EMAIL PROTECTED] wrote: I don't use Shorewall, but rather an iptables script which works for most scenarios: No disrespect, but that sounds too scary for me. I feel more comfortable if something like Shorewall is holding my hand. That is, start with the value the modem is synchronized for, fill the line with the average traffic you expect and lower the values until is OK. As you lower the upstream value you will find increasingly better latency values (try with ping + voip app). Thanks for the explanation. doesn't scale for using across multiple systems of different versions. I didn't understand that bit. What are the systems and versions? Regards Fog_Watch. -- Lose wait. Get Gentoo. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HFSC and that ATM overhead problem (Another VOIP QoS post. Ahhhh)
On Sunday 04 November 2007 23:16, Fog_Watch wrote: On Sun, 4 Nov 2007 12:46:37 + Gustavo Homem [EMAIL PROTECTED] wrote: I don't use Shorewall, but rather an iptables script which works for most scenarios: No disrespect, but that sounds too scary for me. I feel more comfortable if something like Shorewall is holding my hand. Takes more time the first time and less time from then on. That is, start with the value the modem is synchronized for, fill the line with the average traffic you expect and lower the values until is OK. As you lower the upstream value you will find increasingly better latency values (try with ping + voip app). Thanks for the explanation. doesn't scale for using across multiple systems of different versions. I didn't understand that bit. What are the systems and versions? If you manage multiple Linux systems with different versions you realize that patching the kernels for all, and retesting afterwards, takes quite some time. Then if you need a kernel upgrade, there you go again praying that the patches work. The point was: the gain obtained from using those patches might not compensate the time investment, on the scenarios I work with. For a single setup, or multiple identical ones, it will pay off for sure. Cheers Gustavo Regards Fog_Watch. -- Angulo Sólido - Tecnologias de Informação http://angulosolido.pt ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
