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 ------------------------------------------------------------------------- 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]
