"Thank you for your insight, Joe (may i call you Joe?)."
You may.
"I told my bosses that the drops are in acceptable range. Also the stress test was 99.93% successful, which I told them seemed acceptable to me. They disagreed and instructed me to fix it. So here we are."
Without knowing the attributes of your traffic, I cannot say what is, or isn't, truly acceptable. As I wrote earlier, traditionally, the rule-of-thumb, was, drop rate under 1% was acceptable (BTW, this would be end-to-end). That rule-of-thumb predates, I believe, interactive and/or real-time traffic requirements. Personally, I've found most any traffic doesn't have any noticeable issues as long as drop rate doesn't exceed .1% However, there's a very huge difference between truly dropping every 100th (or 1,000th) packet and an average drop rate of 1%.
Simple example, if told the average latency is 50 ms, is that because individual latencies are 50, 50, 50, 50, etc, or 49, 52, 51, 48, etc, or 1, 99, 7, 93, etc.? If you see a difference between these, realize same can happen with drops, i.e. an average calculation, alone, often doesn't tell us all we should know.
Anyway, although many consider zero drop percentage, ideal, and any drops at all, "bad", both views can be very wrong!
TCP, by design, uses drops as a flow rate regulator. Without it, something like a gig port would transmit a whole data stream at the gig rate even though down stream there's a lessor bandwidth link and/or there are other gig senders whose combined traffic exceeds the bandwidth of a downstream link.
As an aside, although some form of flow rate control is critically important, it has been recognized dropping packets might not be the best way to accomplish this.
So, ECN was proposed (using two of the ToS octet's bit's) to convey congestion without dropping a packet. Never really caught on.
Some of the (later) TCP variants, though, take a much keener interest in RTT. If they see RTT suddenly start to spike, they assume the flow is encountering congestion. (See TCP congestion control - look at all the variants trying to deal with this issue!)
Personally, I've long considered "drop management" a key component of QoS, but to manage drops, you need to understand they are sometimes "good", yet the goal is to have a few as possible, while accomplishing our goals.
Hopefully, the above might help you to convince those wanting you to solve the "drops" problem, because, it really might not be a "problem". (Again, although drops might still happen in the most optimal situation, I don't know how close your situation is to "optimal".)
"He states that I "need both" IPP config and DSCP config. You state that I do not. Do you disagree with Reza? (Logic seems to side with you.)"
I do disagree with @Reza Sharifi on this, because both use the same 1st 3 bits of the ToS. (Also see DSCP and Precedence Values.)
Normally you would use the newer standard DSCP, but since they overlay their bit usage, I'll still use both in some situations, but not in a manner as your policy is doing (setting both DSCP and IPP).
For example, rather than something like (my syntax might be off) "match IP DSCP CS4 AF41 AF42 AF43", I'll use something like "match IP precedence 4", although the latter also matches IP DSCP 33, 35, 37, 39.
"It seems to me that in this situation, the VOIP traffic will have equal precedence as this traffic. I am fin with this consequence."
Correct, they would have equal precedence, which often breaks VoIP. But, if VoIP breaking is not a concern, now or in the future, then, agreed, go ahead and use class 5 treatment.
However, VoIP class level (5) traffic is often given absolute priority over ALL other traffic (even routing updates), and because of this, it's sometimes rate limited to preclude this class from breaking ALL other traffic. If breaking ALL other traffic is also a consequence of no concern, again, go ahead. ; )
(BTW, I don't know the attributes of the traffic you want to possible provide class 5 treatment for. I.e. it's also possible, it wouldn't be adverse at all. For example, often VoIP control traffic is also directed into class 5, but it uses so little bandwidth, it's usually not a problem in that class too.)
"1. Is the NON-CoS config even relevant here?"
Yes, it may be, as most Enterprise level equipment, supporting QoS, can use L3 ToS.
"2. Should this config be on the "int port-channel 77" or should it only/also live on the two ports that form the port channel?"
Depends on the platform. Over the years, Cisco's IOSs have permitted more and more to be configured on the PC interface, and IOS will apply to PC links as needed. I.e. it depends on the platform.
3. May you please view below config, then suggest what best config should look like?
policy-map type qos match-first MY-MAP-1
class type qos CLASS-MYCLASS-1
set dscp cs5
set precedence 5 !redundant with set dscp cs5, i.e. you're resetting the same first 3 bits to the same value
set cos 5 !1st assumes VLAN tagged frames - also both this and L3 ToS depend on what QoS treatment, if any, is set aside for this values
BTW, when setting ToS/CoS, big difference whether setting on ingress or egress to device! Setting on ingress, device usually will use that setting for egress treatment. Setting on egress, generally devices ignores for that device treatment, but tag passed along to next device(s).
