Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Enabling DSCP Transparency Mode
The switch supports the DSCP transparency feature. It affects only the DSCP field of a packet at egress. By default, DSCP transparency is disabled. The switch modifies the DSCP field in an incoming packet, and the DSCP field in the outgoing packet is based on the quality of service (QoS) configuration, including the port trust setting, policing and marking, and the DSCP-to-DSCP mutation map.
If DSCP transparency is enabled by using the no mls qos rewrite ip dscp command, the switch does not modify the DSCP field in the incoming packet, and the DSCP field in the outgoing packet is the same as that in the incoming packet.
Note 
Enabling DSCP transparency does not affect the port trust settings on IEEE 802.1Q tunneling ports.
Regardless of the DSCP transparency configuration, the switch modifies the internal DSCP value of the packet, which the switch uses to generate a class of service (CoS) value that represents the priority of the traffic. The switch also uses the internal DSCP value to select an egress queue and threshold.
The above is for a 3750, but likely works the same for your switch.
What is means is the egress packet's ToS will be the same as when the packet entered the switch, however the packet is treated with the logically remarked packet, within the switch.
Is this a contradiction? Or, do you need a service policy? Don't know, as don't know your QoS goals/requirements.
One usage case where you might not want to rewrite the ToS, yet remark traffic for internal treatment, some kind of service provider. I.e. we'll treat the traffic as if it had "this" ToS marking yet will guarantee your original ToS when the packet egresses off our devices/cloud.
