Philip Prindeville wrote: > I'm looking at the astshape code, for a couple of reasons. (a) I want > it to work with Arno's firewall, and (b) I noticed it doesn't quite get > some things right (like bridging or pre-marked traffic). > > So... if anyone has experience with QoS or can shed some light on this, > please jump in. > > I noticed, for a start, that my Sipura handsets (SPA-942's) mark the > DSCP by default. > > For SDP/RTP, they mark EF (0xb8, 101110) and for SIP itself, they mark > AF31 (0x68, 011010). See: > > http://www.cisco.com/en/US/docs/ios/12_2t/12_2t2/feature/guide/ft_dscp.html > > for a discussion of DSCP QoS markings, or RFCs 2597/2598. > > Certain types of bulk traffic that are typically data intensive but not > time sensitive, should also be marked. > > Like SMTP, SMTPS, FTP, HTTP, HTTPS, IMAP, IMAPs, POP, etc. > > So... with that lengthy and rambling preamble (pre-ramble?) done, my > questions are: > > (1) should we just leave pre-marked traffic alone and not re-prioritize > it? Some devices put their SDP/RTP traffic into odd ranges (or ranges > that typically overlap with other stuff) by default. The script as it > is now considers all traffic from ports 10000:20000 to be VoIP media. > That seems a bit excessive/risky. > > (2) There are tests in the code for $BRIDGE0. Hmm. At one site > (Redmond), I have an ADSL card doing RFC-1483 encapsulation (AAL5) > bridged as an ethernet interface (SNAP, of course) with eth0 as br0... > (so I can throw an external ADSL modem onto eth0 if my PCI card ever > goes bad). But on another site (Boise), I have br0 configured as > eth2/eth3 on my internal network. You can't count on $BRIDGE0 to be > internal or external without also looking at $INTIF and $EXTIF. > > (3) Do we want to mark bulk data? This is the main reason for VoIP > being delayed. Putting bulk data into an extremely low category queue > might be good (but then, the default might be adequate for this... I > think uncategorized traffic should go into default, and default be one > notch above "bulk"). > > (4) Do we need to shape ingress (traffic coming from the WAN)? It seems > to me that 99.99% of cases the traffic will either be terminal (for the > Astlinux box) or have a single hop to go over 10/100/1000Mb Ethernet. > Is it worth shaping that? I've never encountered a situation where it > was useful (ok, one once: when the traffic was hairpinned back out a > IPSEC tunnel to a remote site... but that's extremely rare). > > (5) Do we want to make ports specify their protocols? Elsewhere we use > t22 and u53, etc. Seems like this wouldn't be a bad convention to stick > to. Especially if it cuts the number of useless rules down that would > be processed but never match any traffic (like u22). > > Ok, I thought I had more questions than that. I'll probably have more > later. But that's a start. > > Anyone have any suggestions/insights?
Philip, I'm catching up after a long weekend, but just wanted to let you know that I'm not using the existing astshape code. I'm using traffic shaping with the hfsc module with the script referenced on this page: http://automatthias.wordpress.com/2006/06/30/hfsc-and-voip/ Here's the actual script: http://media.blizinski.pl/code/hfsc.gz This appears to work much better than the htb module. Darrick -- Darrick Hartman DJH Solutions, LLC http://www.djhsolutions.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Astlinux-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to [EMAIL PROTECTED]
