This last portion of the proposal is rather radical in scope.
[!] -m dscp_table [--src | --dst ] --transform-via tablename [!] -m dscp_table [--src | --dst ] --lowest tablename [!] -m dscp_table [--src | --dst ] --highest tablename [!] -m dscp_table [--src | --dst ] --best tablename [!] -m dscp_table [--src | --dst ] --worst tablename
Comprehensive port based (re) classification can be accomplished by loading one or several large (132k) tables into the kernel at run time, referenced via the standard load_firmware mechanisms in the kernel, mapping the entire available port space into a bimodal classification mechanism.
Regardless of the actual size of the table, it would actually remain cache hot in the majority of cases, as the most used ports lie below port 1024.
The default match would be against both src and dst ports, the match logic for –best or –worst is kind of undefined. It makes sense for promoting AFxx catagory traffic…
A) Why not a 48k table?
Quite a few protocols are bimodal, where they come in on two different priorities based on the actual usage.
The canonical example of this is SSH, which sets the interactive bit for interactive sessions, and sets bulk for SCP.
It would be my hope that other protocols that are bi-modal would do the same, or at least, could.
Also in analyzing the traffic generated by the top 100 web sites, they generate either CS1 (background) or BE traffic on port 80.  If a given website wants to claim it’s sending bulk data, let them.
So allowing for bimodal capabilities covers more traffic possibilities than a single match.
B) So… why not a 96k table?
Coping with 6 bit values is mildly hairy.
C) So why 128k?
The undefined 4 bits could be used for a variety or purposes.
One potential mapping would include port blocking based on port number and/or direction, thus combining basic firewalling and traffic classification into one rule.
D) But you specified 132k!()??
The first 4k is a header, for future use. Tables could be signed and contracts enforced between providers agreeing to carry traffic of different levels.
Similarly a market for home and business usage could arrive for programming by exception. An example of this is, the author listens to several internet radio stations and likes very much to have reserved enough bandwidth (128k-220k) usually to let music flow while other work is going on. IF there existed (crowdsourced) database(es) out there of ip addresses and port numbers with their usual traffic on them classified, usage can be daily/hourly optimized to match a normal traffic pattern for each site’s specific requirements, starting with a custom table of port mappings to prioritizations, and programming via exception the additional traffic types via (for example) an ipset-like mechanism.
5: http://www.oidview.com/mibs/0/DIFFSERV-DSCP-TC.html 6: I would never have known most web traffic came in as BK rather than BE.
The classic wondershaper contains ACK prioritization for SSH interactive traffic, because the authors cared a lot about ssh. irc, jabber, and other interactive protocols are left to hang in the wind.