Oliver,
Keep in mind that before we had any QoS models and implementations, IP operated in the best effort mode, and for that case, the ToS octet in the IP header was set to 0. For a better-than-best-effort service, IP defined precedence levels and special treatments (throughput, delay, reliability, monetary cost), and every one of them was intended to signify a service better than best effort, consequently resulting into a ToS octet value that was higher than 0 for any traffic that required a different-than-best-effort treatment.
When QoS and DiffServ came in, they maintained the basic logic that a best effort class should be marked with DSCP 0, and a class better than a best effort should be marked with a non-zero DSCP value. In addition, the DSCP values were selected so that to routers not supporting DSCP, the reinterpretation of the DSCP value as a ToS octet more or less closely reflected on the real treatment the class should receive.
Eventually, someone noticed that it would be useful to have a class that is actually worse than best effort - the scavenger class. Technically, there is no problem in having such a class - but how should it be marked? The lowest allowed DSCP value is 0 (best effort), and the DSCP cannot be a negative number. So the only option of marking a scavenger class is to use a non-zero number that obviously will be positive, and so it will give off an impression that it is actually a more important, more significant class than the best effort.
Admittedly, it is a kludge, but in DiffServ, it is perfectly valid - there is no rule in DiffServ that would state that just because one class has a higher DSCP than the other, it is more important. Once again, DSCP values have been designed in a special way to provide reasonable backward compatibility with routers still interpreting the DSCP field as a ToS octet. Beyond that, there is little science to DSCP values.
As for dropping the scavenger class sooner than best effort, this actually depends on the way the policy-map is set up. Dropping is not guaranteed just because of some DSCP value; you need to activate a mechanism that causes the drops. This would be either explicit policing, tail drops (shortening the hold-queue for the scavenger class) and Random Early Detection. Your policy-map does not seem to use any of these mechanisms.
As for marking the scavenger traffic with AF11, I would call it unfortunate, as AF11 is used for traffic that requires certain guarantees. However, if all devices in the network were configured to treat AF11 as a scavenger class, it would work.
Keep in mind - it is you who defines how a particular class is going to be treated. How you mark that class is up to you. You may do it in a standards-compliant way, making it easy for you and someone else to understand, or you may do it according to your personal preference, with the risk that you'll have hard times maintaining it.
Best regards,
Peter
